System, method, and computer program product for identification of vendor and model name of a remote device among multiple network protocols

ABSTRACT

There is provided a method, system, and computer program product for extracting information related to a monitored device communicatively coupled to a network using an HTTP communication protocol. The method includes: retrieving, from a first memory, vendor and model information of the monitored device; determining vendor and model through the web page from the monitored device; obtaining the device state information; and storing, in a second memory, the device information obtained in the accessing step, in association with the vendor and model information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following commonly owned co-pendingU.S. patent applications:

1. Ser. No. 09/453,937 entitled “Method and System of Remote Diagnostic,Control, and Information Collection using a Dynamic Linked Library ofMultiple Formats and Multiple Protocols with Intelligent Formatter,”filed May 17, 2000;

2. Ser. No. 09/756,120 entitled “Method and System of Remote Support ofDevice Using Email,” filed Jan. 9, 2001;

3. Ser. No. 09/782,064 entitled “Method and System of Remote Diagnostic,Control, and Information Collection using a Dynamic Linked Library ofMultiple Formats and Multiple Protocols with Three-Level Formatting,”filed Feb. 14, 2001;

4. Ser. No. 09/921,707 entitled “Universal Controller in The WirelessNetworked Environment,” filed Aug. 6, 2001;

5. Ser. No. 09/953,357 entitled “System, Method, and Computer ProgramProduct for Collecting and Sending Various Types of Information to aMonitor Using Email,” filed Sep. 17, 2001;

6. Ser. No. 09/953,358 entitled “Method and System of Remote Support ofDevice Using Email Through Data Transfer Module,” filed Sep. 17, 2001;

7. Ser. No. 10/831,187 entitled “Method and System of Remote Monitoringand Support of Devices, Extracting Data from Different Types of EmailMessages, and Storing Data According to Data Structures Determined bythe Message Types,” filed Apr. 26, 2004;

8. Ser. No. 09/953,359 entitled “Method and System for Remote Support ofDevice using Email for Sending Information Related to a MonitoredDevice,” filed Sep. 17, 2001;

9. Ser. No. 09/975,938 entitled “Method and System of Remote Monitoringand Support of Devices, Including Handling Email Messages HavingMessages Types Specified Within the Email Message,” filed Oct. 15, 2001;

10. Ser. No. 11/153,543 entitled “Method and System of Remote Support ofDevice Using Email Based Upon POP3 with Decryption Capability ThroughVirtual Function,” filed Jun. 16, 2005;

11. Ser. No. 10/157,905 entitled “Method and Apparatus for MonitoringRemote Devices Through a Local Monitoring Station and Communication Witha Central Station Supporting Multiple Manufacturers,” filed May 31,2002;

12. Ser. No. 10/157,904 entitled “Method and Apparatus for ProvidingMultiple Vendor Support to Remotely Monitored Devices,” Filed May 31,2002;

13. Ser. No. 10/157,903 entitled “Method and Apparatus for ModifyingRemote Devices Monitored by a Monitoring System,” filed May 31, 2002;

14. Ser. No. 10/162,402 entitled “Method and System for MonitoringNetwork Connected Devices and Displaying Device Status,” filed Jun. 5,2002;

15. Ser. No. 10/606,862 entitled “Method and System of Remote PositionReporting Device,” filed Jun. 27, 2003;

16. Ser. No. 11/182,889 entitled “Method and System of Remote PositionReporting Device,” filed Jul. 18, 2005;

17. Ser. No. 11/234,224 entitled “Method and System for ScriptImplementation of HTTP to Obtain Information from Remote Devices,” filedon Sep. 26, 2005;

18. Ser. No. 09/975,935 entitled “Method and System for Remote Supportof Device Using Email Based Upon Pop3 With Decryption Capability ThroughVirtual Function,” filed Oct. 15, 2001;

19. Ser. No. 10/068,861 entitled “Method and Apparatus UtilizingCommunication Means Hierarchy to Configure or Monitor an InterfaceDevice,” filed Feb. 11, 2002;

20. Ser. No. 10/142,989 entitled “Verification Scheme for Email MessageContaining Information About Remotely Monitored Devices,” filed May 13,2002;

21. Ser. No. 10/142,992 entitled “Method for Scrambling Informationabout Network Devices That is Placed in Email Message,” filed May 13,2002;

22. Ser. No. 10/157,903 entitled “Method and Apparatus for ModifyingRemote Devices Monitored by a Monitoring System,” filed May 31, 2002;

23. Ser. No. 10/162,402 entitled “Method and System to Use HTTP andHtml/Xml for Monitoring the Devices,” filed Jun. 5, 2002;

24. Ser. No. 10/167,497 entitled “Method and System of Remote PositionReporting Device,” filed Jun. 13, 2002, which is a continuation of Ser.No. 09/575,702 (U.S. Pat. No. 6,421,608);

25. Ser. No. 10/225,290 entitled “Method and System for MonitoringNetwork Connected Devices with Multiple Protocols,” filed Aug. 22, 2002;

26. Ser. No. 10/328,003 entitled “Method of Accessing Information fromDatabase to be used to Obtain Status Information from the Web Pages ofRemotely Monitored Devices,” filed Dec. 26, 2002;

27. Ser. No. 10/328,008 entitled “Method of using Internal Structure toStore Database Information for Multiple Vendor and Model Support forRemotely Monitored Devices,” filed Dec. 26, 2002;

28. Ser. No. 10/328,026 entitled “Method of using Vectors of Structuresfor Extracting Information from the Web Pages of Remotely MonitoredDevices,” filed Dec. 26, 2002;

29. Ser. No. 10/372,939 entitled “Method and System for MonitoringNetwork Connected Devices with Multiple Protocols,” filed Feb. 26, 2003;

30. Ser. No. 10/460,150 entitled “Method for Efficiently StoringInformation used to Extract Status Information from a Device Coupled toa Network in a Multi-Protocol Remote Monitoring System,” filed Jun. 13,2003;

31. Ser. No. 10/460,151 entitled “Method for Efficiently ExtractingStatus Information Related to a Device Coupled to a Network in aMulti-Protocol Remote Monitoring System,” filed Jun. 13, 2003;

32. Ser. No. 10/460,404 entitled “Method for Parsing an InformationString to Extract Requested Information Related to a Device Coupled to aNetwork in a Multi-Protocol Remote Monitoring System,” filed Jun. 13,2003;

33. Ser. No. 10/460,408 entitled “Method and System for ExtractingVendor and Model Information in a Multi-Protocol Remote MonitoringSystem,” filed Jun. 13, 2003;

34. Ser. No. 10/670,505 entitled “Method and System for ExtractingInformation from Networked Devices in a Multi-Protocol Remote MonitoringSystem,” filed Sep. 26, 2003;

35. Ser. No. 10/670,604 entitled “Method and System for SupportingMultiple Protocols Used to Monitor Networked Devices in a RemoteMonitoring System,” filed Sep. 26, 2003;

36. Ser. No. 10/764,467 entitled “Method and System for Determining theType of Status Information to Extract from Networked Devices in aMulti-Protocol Remote Monitoring System,” filed Jan. 27, 2004;

37. Ser. No. 10/764,527 entitled “Method and System for ManagingProtocols Used to Obtain Status Information from a Network Device,”filed Jan. 27, 2004;

38. Ser. No. 10/764,569 entitled “Method and System for Managing Vendorand Model Information in a Multi-Protocol Remote Monitoring System,”filed Jan. 27, 2004;

39. Ser. No. 10/764,582 entitled “Method and System for InitializingProtocol Information Used to Extract Status Information from NetworkedDevices,” filed Jan. 27, 2004;

40. Ser. No. 10/927,158, entitled “Method and System for Using AbstractClasses to Extract Status Information From Networked Devices,” filedAug. 27, 2004;

41. Ser. No. 10/927,257, entitle “Method and System for Using AbstractClasses to Extract Status Information from Networked Devices,” filedAug. 27, 2004;

42. Ser. No. 10/927,283, entitled “Method of Initializing a DataProcessing Object Associated with a Communication Protocol Used toExtract Status Information Related to a Monitored device,” filed Aug.27, 2004;

43. Ser. No. 11/032,039, entitled “Method and System for ExtractingInformation from Networked Devices Using Multiple Implementations ofProtocol Access Functions,” filed Jan. 11, 2005;

44. Ser. No. 11/032,016, entitled “Monitoring Device Having a MemoryContaining Data Representing Access Information Configured to be Used byMultiple Implementations of Protocol Access Functions to ExtractInformation From Networked Devices,” filed Jan. 11, 2005;

45. Ser. No. 11/032,063, entitled “Monitoring Device Having a MemoryContaining Data Representing Access Information Configured to be Used byMultiple Implementations of Protocol Access Functions to ExtractInformation From Networked Devices,” filed Jan. 11, 2005;

46. Ser. No. 11/032,088, entitled “Method and System for ExtractingInformation From Networked Devices Using the HTTP Protocol andPrecondition Information,” filed Jan. 11, 2005;

47. Ser. No. 11/032,192, entitled “Method and System For ExtractingStatus Information From Networked Devices Using the SNMP Protocol,”filed Jan. 11, 2005;

48. Ser. No. 11/234,322, entitled “Method and System for Use of AbstractClasses for Script Implementation of HTTP to Obtain Information fromDevices,” filed on Sep. 26, 2005;

49. Ser. No. 11/234,319, entitled “Database for Multiple Implementationof HTTP to Obtain Information from Devices,” filed Sep. 26, 2005;

50. Ser. No. 11/234,323, entitled “Method and System for ScriptProcessing in Script Implementation of HTTP to Obtain Information fromDevices,” filed on Sep. 26, 2005;

51. Application Ser. No. 11/517,378, entitled “System, Method, andComputer Program Product for Obtaining Vendor Identification of a RemoteDevice of Merged Companies,” filed Sep. 8, 2006;

52. Application Ser. No. 11/517,363, entitled “system, method, andcomputer program product using the HTTP protocol to extract informationfrom remote devices,” filed Sep. 8, 2006;

53. Application Ser. No. 11/517,362, entitled “system, method, andcomputer program product for extracting information from remote devicesthrough the http protocol,” filed Sep. 8, 2006; and

54. Application Ser. No. 11/517,428, entitled “system, method, andcomputer program product using an SNMP Implementation to obtain vendorinformation from remote devices,” filed Sep. 8, 2006.

The disclosures of each of the above U.S. patents and patentapplications are incorporated herein by reference in their entirety.

The present invention includes the use of various technologiesreferenced and described in the references identified in the followingLIST OF REFERENCES by the author(s) and year of publication of thereference:

LIST OF REFERENCES

[1] Goldfart, C., The SGML Handbook. Clarendon Press (1990);

[2] Castro, E., HTML for the World Wide Web, Peachpit Press, Berkeley(1996); and

[3] Megginson, D., Structuring XML Documents, Prentice Hall, N.J.(1998).

The entire contents of each reference listed in the LIST OF REFERENCESare incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the monitoring of devices connected to anetwork. More particularly, it relates to a method, system, and computerprogram product for the remote monitoring of network-connected devicesusing multiple protocols.

2. Discussion of the Background

As is generally known, computer systems include hardware and software.Software includes a list of instructions that are created to operate andmanage hardware components that make up a computer system. Typically,computer systems include a variety of hardware components/devices thatinterface with one another. The computer system can be a stand-alonetype or a networked type. In a networked-type computer system, aplurality of distinct devices are connected to a network and thuscommunication between these distinct devices is enabled via the network.

Further, software for operating the hardware devices must be configuredin order to allow communication between the hardware devices so that thehardware devices are enabled to function cooperatively. Further, inorder to facilitate such a communication, it is also desirable forhardware devices to be monitored and the status of each hardware deviceidentified in order to ensure that each hardware device is functioningin an efficient manner.

For the purposes of this patent application, the inventor has determinedthat a hardware device that is controlling, configuring, or monitoringthe plurality of distinct devices or hardware devices would be referredto as a monitoring device and the hardware devices that are beingcontrolled, configured, or monitored by the monitoring device would bereferred to as “monitored devices.”

For hardware devices that are located on a network, it is desirable forthese devices to be monitored for maintenance, usage, or other purposes.However, in view of manufacturer differences relating to hardwaredevices and interfaces, it may be difficult for a monitoring device tocommunicate with various other devices connected to a network. Such adisadvantage most likely prevents network administrators from obtainingcrucial information about the performance and efficiency of the devicesconnected to the network.

The Simple Network Management Protocol (SNMP) is today a de-factoindustry standard for the monitoring and management of devices on datacommunication networks, telecommunication systems and other globallyreachable devices. Practically every organization dealing with computersand related devices expects to be able to centrally monitor, diagnose,and configure each such device across local- and wide-area networks.SNMP is the protocol that enables this interaction.

In order for a device to respond to SNMP requests, it is desirable toequip the device with the software that enables it to properly interpretan SNMP request, perform the actions required by that request, andproduce an SNMP reply. The SNMP agent software is typically a subsystemsoftware module residing in a network entity.

The collection of objects implemented by a system is generally referredto as a Management Information Base (MIB). An MIB may also be a databasewith information related to the monitoring of devices. Examples of otherMIB's include Ethernet MIB, which focuses on Ethernet interfaces; BridgeMIB, which defines objects for the management of 802.1D bridges, to namea few.

Using SNMP for monitoring devices is difficult as private MIB's includevalues that are hard to decipher without a valid key. A company usingSNMP for monitoring various devices connected to its network creates aunique identifier/key that is maintained as proprietary information ofthe company. For the most part, the results are displayed as binary orinteger values. Thus, using SNMP, results received from the devices thatare being monitored (“monitored devices”) fail to provide a user withthe status of the monitored devices in a user comprehensible manner.

Further, using SNMP, it is difficult for one to obtain detailedinformation about a monitored device without a valid key or access to aprivate MIB to decipher the results obtained as binary or integervalues. In addition, a given protocol (e.g., SNMP or HTTP/HTML) may failfor various reasons, such as time out or lost packets. Also, someinformation extracted from a given device using the multiple protocolsmay be duplicated for each protocol. Accordingly, if the extraction ofdata from the device is not properly managed in such situations, timeand memory inefficiencies result since some protocols require moreresources than other protocols. In addition, information extractionusing some protocols may require much less processing and memory thanusing others. Furthermore, some information obtained through oneprotocol may be more useful for the monitoring device than the oneobtained through another protocol.

SNMP has a standard command to retrieve the Enterprise Object Identifier(OID) and the System Description. However, many printers include anincorrect OID to identify the vendor of the printer. For example, theinventors of the present application have observed that some models ofSamsung and Brother use HP OID for their printers. Also, when companiesmerge or are acquired, the old OID may still be used in some machines.

Another technique to identify the vendor is to use the systemdescription. However, in one case, the inventors of the presentapplication observed that the System Description did not contain thevendor name, but the Enterprise OID did contain the vendor name. Forexample, the inventors of the present application have observed thatsome models of Konica Minolta do not contain the vendor name.

Many digital copiers, printers, and Multi Function (MF) machines have aweb server through which the vendor name can be obtained using abrowser. HTML has an advantage over SNMP because the informationobtained using HTML is human readable. Unlike private MIB information inSNMP, any information obtained through HTML can be understood by ahuman. Therefore, meaningful information can be obtained from machinesby using the HTTP communication protocol.

Furthermore, vendor names and/or model names of a machine may bedifferent when the vendor name and the model name are obtained throughthe use of different protocols. For example, SNMP Enterprise OID mayindicate Minolta, while HTTP may indicate Konica Minolta. The reason forthis discrepancy is that Konica and Minolta merged. In some cases, thevendor name and/or model name may differ in terms of capitalization. Forexample, SNMP may indicate HP, while HTTP may indicate hp. In anothercase, the initials, such as HP, of a company may be used in oneprotocol, while the full company name may be used in another protocol.The inventors of the present application have recognized a problem inworking with different vendor and/or product model names and a need toobtain uniform vendor and/or product model names.

Although human readable information can be extracted from machines byusing HTTP/HTML processing, there is no need to perform the functions ofa browser to extract the needed information. The inventors of thepresent application have recognized a need to simplify the process ofextracting information using HTTP/HTML processing.

SUMMARY OF THE INVENTION

The system and method of the present invention addresses solutions tothe above-identified problems by enabling monitoring of devices that areconnected to a network. Accordingly, a method of monitoring a deviceamong distinct devices communicatively coupled to a network isdescribed.

The method includes accessing a first database via a hardware accessmodule, the first database being configured to support a plurality ofcommunication protocols. The first database is stored with informationused by the plurality of communication protocols in order to obtainvarious information, such as manufacturer and model information of amonitored device. A communication protocol is selected from among aplurality of communication protocols, and the selected communicationprotocol is configured to receive state information from the monitoreddevice. The method further includes accessing the monitored device usingthe selected communication protocol and information from the firstdatabase, receiving state information from the accessed device, andstoring the received state information in a second database(DeviceODBC). State information includes Dynamic, Semi-Static and StaticState information. Dynamic State information refers to state informationthat is changing frequently, such as page count, toner level, oil andgas levels of an automobile and so on. Semi-Static State informationrefers to state information that is infrequently changing, such as IPaddress, time zone, and options of a monitored device. Static Stateinformation refers to state information that does not change over thelife of the machine. When word “status” is used, status refers to stateinformation as defined in this invention.

In another embodiment, the present invention provides a method ofmonitoring a device among distinct devices communicatively coupled to anetwork. A plurality of communication protocols may be used to retrieveinformation from a monitored device. For example, an SNMP protocol isfirst selected to access a monitored device, and device information thatis configured to be efficiently retrieved using the SNMP protocol isobtained. Subsequently, HTTP and FTP protocols are selected to obtaininformation that was incapable of efficient retrieval using the SNMPprotocol if the device supports the additional protocols. The selectionof protocols is performed by a protocol manager in conjunction withsupport information stored in a database.

In the present invention, a monitoring system enables the monitoring ofat least one device (monitored device) connected to a network, such as,for example, a LAN or a WAN. The monitored device is configured to havea unique IP address. The IP address allocated to the monitored device,and the details of the vendor/manufacturer for the monitored device, arestored in a database. By scanning the network and interrogating thedevices the IP addresses of the devices can be obtained. Such methodsare known. Therefore, it is assumed that IP addresses of the devices tobe monitored are already acquired and stored in a database.

The present invention specifies how to extract necessary informationfrom the HTML information received from a monitored device. Once a webpage location of the monitored device is accessed (i.e., through the IPaddress and the specified port), a specific web page corresponding tothe monitored device is obtained. Information in the web page containsvarious state information. For example, the toner level may be shown as“Black 100%” in the color printer web page. The required information andparameter values extracted from the web page using string matching arestored in the database.

The present invention also identifies various vendors of monitoreddevices and the device models that are supported by the monitoringsystem as described herein. Since various vendors of the monitoreddevices present information about a monitored device in avendor-specific manner, the present invention enables the identificationof the vendor and model of the monitored device to determine theoperational state of the monitored device.

According to one aspect of the present invention, there is provided amethod, system, and computer program product for extracting informationrelated to a monitored device communicatively coupled to a network usingan HTTP communication protocol, comprising: retrieving, from a firstmemory, vendor and model information of the monitored device;determining vendor and model through the web page from the monitoreddevice; obtaining the device state information; and storing, in a secondmemory, the device information obtained in the accessing step, inassociation with the vendor and model information.

According to another aspect of the present invention, there is provideda method, system, and computer program product for extracting vendor andmodel information from various protocols and synchronizing to thenormalized vendor and model information.

In another embodiment of the present invention, a method of extractinginformation related to a monitored device communicatively coupled to anetwork using an SNMP communication protocol includes: accessing themonitored device using the SNMP communication protocol to obtain firstinformation from the monitored device; attempting to extract vendorinformation from the obtained first information; if the vendorinformation was extracted from the first information, storing the vendorinformation in a storage device; and if the vendor information was notextracted from the first information, accessing the monitored deviceusing the SNMP communication protocol to obtain second information,different from the first information, from the monitored device;attempting to extract vendor information from one of the firstinformation and second information; and if the vendor information wasextracted from the second information, storing the vendor information inthe storage device.

In another embodiment of the present invention, a method fortransforming a vendor name of a monitored device includes: accessing themonitored device using a first communication protocol to obtaininformation from the monitored device; determining a vendor name of themonitored device based on the information obtained from the monitoreddevice; and determining, using the determined vendor name, a normalizedvendor name of the monitored device.

In another embodiment of the claimed invention, a method for determininga normalized vendor name and a normalized model name of a monitoreddevice in which information obtained from the monitored device varies inaccordance with a communication protocol used includes: accessing themonitored device using a first communication protocol to obtaininformation from the monitored device; determining a vendor name and amodel name of the monitored device from the information obtained fromthe monitored device; determining, using the vendor name, a normalizedvendor name of the monitored device; and determining, using thenormalized vendor name and the determined model name, a normalized modelname of the monitored device.

In another embodiment of the present invention, a method of extractinginformation related to a monitored device communicatively coupled to anetwork using an HTTP communication protocol includes: obtaining awebpage address and a corresponding plurality of model names; accessinga webpage using the obtained webpage address; parsing the accessedwebpage to attempt to find at least one of the plurality of model names;and if one of the model names is found in the parsing step, thennormalizing the found model as the model name of the monitored device.

In another embodiment of the present invention, a method of extractinginformation related to a monitored device communicatively coupled to anetwork using an HTTP communication protocol includes: retrieving, froma first memory, a vendor name of the monitored device; accessing adatabase to obtain a vector corresponding to the vendor name of themonitored device, wherein the vector includes a web page address and atleast one key string associated with the information to be extracted;obtaining a line from the web page using the obtained web page address;parsing the line to determine if a first key string in the at least onekey string is included in the line; repeating the obtaining and parsingsteps for each key string in the at least one key string until a keystring in the at least one key string has been found; and extracting theinformation from a line of the webpage following a line determined toinclude the last of the at least one key string.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendantadvantages thereof will be readily obtained as the same becomes betterunderstood by reference of the following detailed description whenconsidered in connection with the accompanying drawings, wherein:

FIG. 1 illustrates networked business office devices connected to anetwork of computers and databases through the Internet;

FIG. 2 illustrates the components of a digital image forming apparatus;

FIG. 3 illustrates the electronic components of the digital imageforming apparatus illustrated in FIG. 2;

FIG. 4 illustrates details of a multi-port communication interfaceillustrated in FIG. 3;

FIG. 5 illustrates an alternative system configuration in which businessoffice devices are either connected directly to the network or connectedto a computer which is connected to the network;

FIG. 6A is a block diagram illustrating a flow of information to andfrom an application unit using electronic mail;

FIG. 6B illustrates an alternative way of communicating using electronicmail in which a computer that is connected to the application unit alsoserves as a Message Transfer Agent (MTA);

FIG. 6C illustrates an alternative way of communicating using electronicmail in which an application unit includes a message transfer agent forexchanging electronic mail;

FIG. 6D illustrates an alternative way of communicating using electronicmail in which a mail server acts as a POP3 server to receive mail for anappliance/device and as an Simple Mail Transfer Protocol (SMTP) serverto send mail for the appliance/device;

FIG. 7 illustrates an alternative manner of sending messages across theInternet;

FIG. 8 illustrates an exemplary computer which may be connected to anappliance/device and used to communicate;

FIG. 9 is a schematic representation of the overall system in accordancewith an exemplary embodiment of the present invention;

FIG. 10 illustrates modules used in the monitoring of the data and theirinterface functions in accordance with an exemplary embodiment of thepresent invention;

FIG. 11 shows details within the Monitor module and their callingfunctions between the sub-modules;

FIG. 12 shows the sequence of the init function of the Monitor moduleillustrated in FIG. 10;

FIG. 13 shows an exemplary sequence of the status monitor function todetermine the status of a monitored device by the MonitorManager, asshown in FIG. 11;

FIG. 14 shows a vector of the reference to the devices created byCDeviceFactory and used by the MonitorManager, as illustrated in FIG.12;

FIG. 15 illustrates the SParameter data structure used to storeparameter values necessary to access monitored devices according to oneembodiment of the present invention;

FIG. 16 illustrates a map structure used to store parameter valuesnecessary to access monitored devices according to one embodiment of thepresent invention;

FIG. 17 illustrates the organization of the monitor database used in oneembodiment of the present invention;

FIGS. 18 and 20 illustrate the organization of a support databasearranged according to communication protocol according to one embodimentof the present invention;

FIG. 19 is a diagram illustrating the organization of a support databasefor the HTTP protocol according to one embodiment of the presentinvention;

FIG. 21 is a diagram illustrating the organization of a support databasefor normalizing vendors and models according to one embodiment of thepresent invention;

FIG. 22 illustrates the package diagram of the HWaccess packageaccording to one embodiment of the present invention;

FIG. 23 illustrates a data structure used in the HWaccess module of FIG.22 to maintain information necessary to access the monitored devices andto obtain status information from the monitored devices according to oneembodiment of the present invention;

FIG. 24 is a sequence diagram of the initialization of the class objectswhen init( ) of the Monitor package is called;

FIG. 25 is a sequence diagram of canAccessIP( ) of the HWaccess packageto determine if the device is accessible by any protocol;

FIG. 26 is a sequence diagram for obtaining vendor information, modelinformation, and an unique ID from a monitored device through CHWaccessobject;

FIG. 27 shows a flowchart describing how the data structure used by thesoftware objects representing the monitored devices is updated todetermine which protocols are used to obtain status information for amonitored device according to one embodiment of the present invention;

FIG. 28 shows a flowchart describing the process of obtaining statusinformation from a monitored device using all of the communicationprotocols according to one embodiment of the present invention;

FIG. 29 illustrates the data structures used to store and maintain thestatus information of a monitored device of a specific vendor and modelfor each protocol according to one embodiment of the present invention;

FIG. 30 illustrates a data structure used in the CNormalizedVendorModelobject of FIG. 22 to maintain information about the vendors found in amonitored device and the normalized vendor name;

FIG. 31 illustrates a data structure used in the CNormalizedVendorModelobject of FIG. 22 to maintain information about the models supported bythe system and the normalized model name that will be used;

FIG. 32 illustrates a data structure used in the CNormalizedVendorModelobject of FIG. 22 to maintain information about the identifier of themodels supported by the system;

FIG. 33 illustrates the class diagram of the NormalizedVendorModelODBCpackage for accessing normalized vendor and model information from thedatabase;

FIG. 34 is a flowchart describing the process of determining thenormalized vendor name and normalized model name from the vendor nameand model name obtained by a protocol from a device;

FIG. 35 illustrates the package diagram of the HTTP package supportingthe extraction of information from web pages;

FIG. 36 illustrates a data structure used in the HTTP package of FIG. 35to extract information from the web pages;

FIG. 37 illustrates the package diagram of the HTTPaccess package ofFIG. 35 that supports the access and processing of web pages to extractinformation;

FIG. 38 illustrates the package diagram of the HTTPODBC package of FIG.35 that supports the access to the database to obtain information toextract information from the web pages of devices of various vendors andmodels;

FIG. 39 illustrates a data structure used in the HTTP package of FIG. 35to extract the model name from the web pages;

FIG. 40 illustrates a data structure used in the HTTP package of FIG. 35to extract the unique identifier from the web pages;

FIG. 41 illustrates a data structure used in the HTTP package of FIG. 35to extract the status information from the web pages for all devicesthat are monitored;

FIG. 42 illustrates a data structure used in the HTTP package of FIG. 35to extract the status information from a web page of a device;

FIG. 43 is a sequence diagram for obtaining vendor name, model name, andunique identifier from the device's web pages;

FIG. 44 is a flowchart describing the process of obtaining the modelname from the web page of a device that will use the data structure ofFIG. 39;

FIG. 45 is a sample portion of a web page of a device that contains themodel name of the device;

FIG. 46 shows sample values for the data structure of FIG. 39 used toobtain the model name from the web page shown in FIG. 45;

FIG. 47 is a flowchart describing the process of obtaining the statusinformation from the web page of a device that will use the datastructures of FIGS. 41 and 42;

FIG. 48 is a sample portion of a web page of a device that containsstatus information;

FIG. 49 shows sample values for the data structure of FIG. 41 used toobtain status information from the web page shown in FIG. 48;

FIG. 50 shows sample values for the data structure of FIG. 42 used toobtain status information from the web page shown in FIG. 48;

FIG. 51 shows the package diagram of the SNMP package used to extractinformation from the MIB of a device;

FIGS. 52, 53, and 54 are data structures of the SNMP package used forobtaining the model name, unique ID, and status information from the MIBof a device;

FIG. 55 is a data structure of the SNMP package used for mapping thenormalize vendor and model name with the vendor and model name as knownby SNMP; and

FIG. 56 is a flowchart describing the process of obtaining the vendorname, model name, and unique ID of the device.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a schematic having various devices and computers formonitoring, diagnosing, and controlling the operation of the devices.Specifically, FIG. 1 includes a first network 16, such as a Local AreaNetwork (LAN) connected to computer workstations 17, 18, 20, and 22. Theworkstations can be any type of computers including, e.g., PersonalComputer devices, Unix-based computers, Linux-based computers, or AppleMacintoshes. Also connected to the network 16 are a digitalimage-forming apparatus 24, a facsimile machine 28, and a printer 32. Aswould be appreciated by one of ordinary skill in the art, two or more ofthe components of the digital copier/printer/multi-function machine (MF)24 and the facsimile machine 28 can be combined into a unified “imageforming apparatus.” For example, the copier/printer/MF 24, facsimilemachine 28, the printer 32, and the workstations 17, 18, 20, and 22 maybe referred to as machines or monitored devices. In some configurations,one or more workstations may be converted to business office appliances.In addition, any network business office appliance/device can beattached to the network 16. Also, any workstation 17, 18, 20, and 22,and office appliance 27 can function as an intermediate monitoringdevice to poll the monitored devices on the network 16 and to send thecollected data to the monitoring device.

One example of such a business office appliance is eCabinet® from RicohCorporation. Also, a facsimile server (not illustrated) may be connectedto the network 16 and have a telephone (cellular or conventional),cable, or wireless connection. Each of the digital copier/printer/MF 24,facsimile machine 28, and printer 32, in addition to being connected tothe network 16, may also include telephone (cellular or conventional)and/or cable and/or wireless connections 26, 30, and 34, respectively.As explained below, the monitored devices 24, 28, and 32, communicatewith a remote monitoring, diagnosis, and control station, also referredto as a monitoring device, through, for example, the Internet via thenetwork 16 or by a direct telephone (cellular or conventional),wireless, or cable connection.

In another exemplary business environment, monitored devices may includesuch devices as a multi-function imaging device, a scanner, a projector,a conferencing system, and a shredder. In another application, thenetwork 16 may be a home network where monitored devices are meters(electricity, gas, water) or appliances such as, for example, microwaveoven, washer, dryer, dishwasher, home entertainment system,refrigerator, rice cooker, heater, air condition, water heater, securitycamera.

In FIG. 1, a wide area network (WAN) (e.g., the Internet or itssuccessor) is generally designated by 10. The WAN 10 can be either aprivate WAN, a public WAN, or a hybrid type. The WAN 10 includes aplurality of interconnected computers and routers designated by 12A-12I.The manner of communicating over a WAN is known through a series ofRequest for Comments (RFC) documents available from the InternetEngineering Task Force (IETF) at www.ietf.org/rfc.html. Some of thedocuments are RFC 821, entitled “Simple Mail Transfer Protocol”; RFC822, entitled “Standard for the Format of ARPA Internet Text Message”;RFC 959, entitled “File Transfer Protocol (FTP)”; RFC 2045, entitled“Multipurpose Internet Mail Extensions (MIME) Part One: Format ofInternet Message Bodies”; RFC 1894, entitled “An Extensible MessageFormat for Delivery Status Notifications”; RFC 1939, entitled “PostOffice protocol—Version 3”; RFC 2068, “Hypertext TransferProtocol—HTTP/1.1”; and RFC 2298, entitled “An Extensible Message Formatfor Message Disposition Notifications.” The contents of each of thesereferences are incorporated herein by reference.

Transmission Control Protocol/Internet Protocol (TCP/IP) relatedcommunication is described, for example, in the book “TCP/IPIllustrated,” Vol. 1, The Protocols, by W. R. Stevens, fromAddison-Wesley Publishing Company, 1994, the entire contents of which isincorporated herein by reference. Volumes 1-3 of “Internetworking withTCP/IP” by Comer and Stevens are also incorporated herein by referencein their entirety.

Continuing to refer to FIG. 1, a firewall 50A is connected between theWAN 10 and the network 16. A firewall is a device that allows onlyauthorized computers on one side of the firewall to access a network,computers, or individual parts on the other side of the firewall.Firewalls are known and commercially available devices and/or software.Similarly, firewalls 50B and 50C separate the WAN 10 from a network 52and a workstation 42, respectively. Additional details on firewalls canbe found in “Firewalls and Internet Security” by W. R. Cheswick, and S.M. Bellovin, 1994, Addison Wesley Publishing, and “Building InternetFirewalls” by D. B. Chapman and E. D. Zwicky, 1995, O'Reilly &Associates, Inc. The entire contents of those two references areincorporated herein by reference.

The network 52 is a conventional network and includes a plurality ofworkstations 56, 62, 68, and 74. These workstations may be located in adistributed fashion within different departments (e.g., sales, orderprocessing, accounting, billing, marketing, manufacturing, designengineering, and customer service departments) within a single company.In addition to the workstations connected via the network 52, aworkstation 42 that is not directly connected to the network 52 is alsoprovided. Information in a database stored in a disk 46 connected to theworkstation 42 may be shared using proper encryption and protocols, suchas Virtual Private Network (VPN), over the WAN 10 to the workstationsconnected directly to the network 52. Also, the workstation 42 caninclude a direct connection to a private network 44, and the database indisk 46 may be accessed through the private network 44. The cablenetwork used by this invention may be implemented using a cable networkthat is typically used to carry television programming, a cable thatprovides for high-speed communication of digital data typically usedwith computers or the like, or any other desired type of cable.

In another embodiment, the workstation 42 can be a laptop computer, aPDA, a palm top computer, or a cellular phone with network capability.These devices may be used to access information stored in the databasestored in the disk 46.

Information related to digital copier/printer/MF 24, office appliance27, facsimile machine 28, or printer 32, respectively, may be stored inone or more of the databases stored in the disks 46, 54, 58, 64, 70, and76. Known databases include (1) databases by Microsoft, IBM, and Oracle;(2) other relational databases; and (3) non-relational databases(including object-oriented databases). Each of the sales, orderprocessing, accounting, billing, customer service, marketing,manufacturing, and engineering departments may have their own databaseor may share one or more databases. Each of the disks used to storedatabases is a non-volatile memory such as a hard disk or optical disk.Alternatively, the databases may be stored in any storage deviceincluding solid state and/or semiconductor memory devices. For example,disk 64 may be stored with a marketing database, disk 58 may be storedwith a manufacturing database, disk 70 may be stored with an engineeringdatabase, and disk 76 may be stored with a customer service database.Alternatively, the disks 54 and 46 may be stored with one or more of thedatabases.

In addition to the workstations 56, 62, 68, 74, and 42 being connectedto the WAN 10, these workstations may also include a connection to aprivate network for providing a secure connection to a machine/devicebeing monitored, diagnosed, and/or controlled. Additionally, if one ofthe communication media is not operating properly, one of the others maybe automatically used, as a backup, for communication.

A feature of the present invention is the use of a “store-and-forward”mode of communication (e.g., Internet electronic mail, also referred toherein as e-mail) or transmission between a machine and acomputer/monitoring system for diagnosing and controlling the machine.Alternatively, the message which is transmitted may be implemented usinga mode of communication that makes direct, end-to-end connections (e.g.,using a socket connection to the ultimate destination) such as FTP andHyper Text Transfer Protocol (HTTP).

FIG. 2 illustrates the mechanical layout of the digital copier/printer24 illustrated in FIG. 1. In FIG. 2, 101 is a fan for the scanner, 102is a polygonal mirror used with a laser printer, and 103 designates an Fθ lens used to collimate light from a laser (not illustrated). Referencenumeral 104 designates a sensor for detecting light from the scanner.Reference numeral 105 designates a lens for focusing light from thescanner onto the sensor 104, and reference numeral 106 designates aquenching lamp used to erase images on the photoconductive drum 132.There is a charging corona unit 107 and a developing roller 108.Reference numeral 109 designates a lamp used to illustrate a document tobe scanned and elements 110, 111, and 112 designate mirrors forreflecting light onto the sensor 104. A drum mirror 113 is provided toreflect light to the photoconductive drum 132 originating from thepolygon mirror 102. A fan 114 is used to cool the charging area of thedigital image forming apparatus, and a first paper feed roller 115 isused for feeding paper from the first paper cassette 117, and areference numeral 116 designates a manual feed table. Similarly, asecond feed paper feed roller 118 is used in conjunction with the secondcassette 119. Reference numeral 120 designates a relay roller, 121designates a registration roller, 122 designates an image densitysensor, and 123 designates a transfer/separation corona unit. Referencenumeral 124 designates a cleaning unit, 125 designates a vacuum fan, 126designates a transport belt, 127 designates a pressure roller; and 128designates an exit roller. A hot roller 129 is used to fix toner ontothe paper, 130 designates an exhaust fan, and a main motor 131 is usedto drive the digital copier/printer 24.

FIG. 3 is a block diagram illustrating the electronic components of thedigital copier/printer/MF 24 of FIG. 2, wherein CPU 160 is amicroprocessor that acts as a controller of the apparatus. Random accessmemory (RAM) 162 stores dynamically changing information includingoperating parameters of the digital copier/printer/MF 24, such asdynamic state data. A non-volatile memory (e.g., a read only memory(ROM) 164 or a Flash Memory) stores program code used to run the digitalcopier/printer/MF as well as static-state data, describing thecopier/printer/MF 24 (e.g., the model name, model number, serial numberof the device, and default parameters). In addition, some of thenon-volatile memory, such as Flash Memory and a Hard Disk, may storedynamic state data and semi-static state data.

A multi-port network interface 166 is provided to enable the digitalcopier/printer/MF 24 to communicate with external devices through atleast one communication network. Reference number 168 represents awireless or cellular network, and numeral 170 represents another type ofnetwork different from the network identified at 168. Additional detailsof the multi-port network interface are set forth with respect to FIG.4. An interface controller 172 is used to connect an operation panel 174to a system bus 186. The operation panel 174 includes standard input andoutput devices found on a digital copier/printer/MF 24 including a copybutton, keys to control the operation of the image forming apparatussuch as, for example, number of copies, reduction/enlargement,darkness/lightness, etc. Additionally, a liquid crystal display may beincluded within the operation panel 174 to display parameters andmessages of the digital copier/printer/MF 24 to a user.

A local connection interface 171 is a connection through local portssuch as RS232, the parallel printer port, USB, and IEEE 1394. FireWire(IEEE 1394) is described in Wickelgren, I., “The Facts About “FireWire”,IEEE Spectrum, April 1997, Vol. 34, Number 4, pp. 19-25, the entirecontents of which are incorporated herein by reference. Preferably, a“reliable” communication protocol is used which includes error detectionand retransmission.

A storage interface 176 connects storage devices to the system bus 186.For example, the storage devices include a flash memory 178, which canbe substituted by a conventional Electrically Erasable Programmable ReadOnly Memory (EEPROM), and a disk 182. The disk 182 may be a hard disk,optical disk, and/or a floppy disk drive. Additional memory devices maybe connected to the digital copier/printer/MF 24 via connection 180. Theflash memory 178 is used to store semi-static state data that describesparameters of the digital copier/printer/MF 24 that infrequently changeover the life of the apparatus 24. Such parameters include, for example,the options and configuration of the digital copier/printer. An optioninterface 184 allows additional hardware, such as an external interface,to be connected to the digital copier/printer/MF 24. A clock/timer 187is utilized to keep track of both the time and date and also to measureelapsed time.

FIG. 3 also illustrates the various sections making up the digitalcopier/printer/MF 24. Reference numeral 202 designates a sorter andcontains sensors and actuators that are used to sort the output of thedigital copier/printer/MF 24. A duplexer 200 allows performance of aduplex operation. The duplexer 200 includes conventional sensors andactuators. A large capacity tray unit 198 is provided for allowing papertrays holding a large number of sheets. As with the duplexer 200, thetray unit 198 includes conventional sensors and actuators as well.

A paper feed controller 196 is used to control the operation of feedingpaper into and through the digital image forming device. A scanner 194is used to scan images into the digital image forming device andincludes conventional scanning elements such as a light, mirror, etc.Additionally, scanner sensors are used such as a home position sensor todetermine that the scanner is in the home position, and a lampthermistor is used to ensure proper operation of the scanning lamp. Aprinter/imager 192 prints the output of the digital image formingdevice, and includes a conventional laser printing mechanism, a tonersensor, and an image density sensor. The fuser 190 is used to fuse thetoner onto the page using a high temperature roller and includes an exitsensor, a thermistor to assure that the fuser 190 is not overheating,and an oil sensor. Additionally, there is an optional unit interface 188used to connect to optional elements of the digital image forming devicesuch as an automatic document feeder, a different type ofsorter/collator, or other elements which can be added to the digitalimage forming device. Other elements include a GPS unit that canidentify the location of the device.

FIG. 4 illustrates details of the multi-port network interface 166. Thedigital image forming device may communicate to external devices througha cellular interface 227, a wireless interface 228, or an Ethernetinterface 230, which connects to a LAN 170. Other interfaces mayinclude, but are not limited to, a Digital Subscriber Line (DSL)(original DSL, concentric DSL, and asymmetric DSL).

The CPU or other microprocessor or circuitry executes a monitoringprocess to monitor the state of each of the sensors of the digital imageforming device, and a sequencing process is used to execute theinstructions of the code used to control and operate the digital imageforming device. Additionally, there is (1) a central system controlprocess executed to control the overall operation of the digital imageforming device, and (2) a communication process used to assure reliablecommunication to external devices connected to the digital image formingdevice. The system control process monitors and controls data storage ina static state memory (e.g., the ROM 164 of FIG. 3), a semi-static statememory (e.g., the flash memory 178 or disk 182), or the dynamic statememory (e.g., a volatile or non-volatile memory (e.g., the RAM 162, theflash memory 178, or disk 182). Additionally, the static state memorymay be a device other than the ROM 164 such as a non-volatile memoryincluding either of the flash memory 178 or disk 182.

The above details have been described with respect to a digital imageforming device, but the present invention is equally applicable to otherbusiness office machines or devices such as an analog copier, afacsimile machine, a scanner, a printer, a facsimile server, projector,conferencing equipment, shredder, or other business office machines, abusiness office appliance, or other appliances (e.g., a microwave oven,VCR, DVD, digital camera, digital camcorders, cellular phone, palm topcomputer). Additionally, the present invention includes other types ofdevices that operate using store-and-forward or direct connection-basedcommunication. Such devices include metering systems (including gas,water, or electricity metering systems), vending machines, or anymechanical device (e.g., automobiles, motorcycles, washer, and dryer)that needs to be monitored during operation or remote diagnosis. Inaddition to monitoring special purpose machines and computers, theinvention can be used to monitor, control, and diagnose a generalpurpose computer that would be the monitored and/or controlled device.

FIG. 5 illustrates an alternative system diagram of the presentinvention in which different devices and subsystems are connected to theWAN 10. However, there is no requirement to have each of these devicesor subsystems as part of the invention. Each component or subsystemillustrated in FIG. 5 is individually part of the invention. Further,the elements illustrated in FIG. 1 may be connected to the WAN 10 whichis illustrated in FIG. 5. In FIG. 5, there is illustrated a firewall50-1 connected to an intranet 260-1. A service machine 254 connected tothe intranet 260-1 includes therein, or has connected thereto, data 256that may be stored in a database format. The data 256 includes history,performance, malfunction, and any other information such as statisticalinformation of the operation or failure or set-up of the monitoreddevices, or configuration information such as which components oroptional equipment is included with the monitored devices. The servicemachine 254 may be implemented as the device or computer that requeststhe monitored devices to transmit data, or that requests that remotecontrol and/or diagnostic tests be performed on the monitored devices.The service machine 254 may be implemented as any type of device, and ispreferably implemented using a computerized device such as a generalpurpose computer. Also, Service Machine 254 may consist of multiplecomputers over the network with diverse database including billing,accounting, service processing, parts tracking and reports.

Another sub-system of FIG. 5 includes a firewall 50-2, an intranet260-2, and a printer 262 connected thereto. In this sub-system, thefunctions of sending and receiving electronic messages by the printer262 (and similarly by a copier 286) are performed by (1) circuitry, (2)a microprocessor, or (3) any other type of hardware contained within ormounted to the printer 262 (i.e., without using a separate generalpurpose computer).

An alternate type of sub-system includes the use of an Internet ServiceProvider 264, which may be any type of Internet Service Provider (ISP),including known commercial companies such as America Online, Earthlink,and Niftyserve. In this sub-system, a computer 266 is connected to theISP 264 through a digital or analog modem (e.g., a telephone line modem,a cable modem, modems which use any type of wires such as modems usedover an Asymmetric Digital Subscriber Line (ADSL), modems that use framerelay communication, wireless modems such as a radio frequency modem, afiber optic modem, or a device that uses infrared light waves). Further,a business office device 268 is connected to the computer 266. As analternative to the business office device 268 (or any other deviceillustrated in FIG. 5), a different type of machine may be monitored orcontrolled such as a digital copier, any type of appliance, securitysystem, or utility meter, such as an electrical, water, or gas utilitymeter, or any other device discussed herein.

Also illustrated in FIG. 5 is a firewall 50-3 connected to a network274. The network 274 may be implemented as any type of computer network,(e.g., an Ethernet or token ring network). Networking software that maybe used to control the network includes any desired networking softwareincluding software commercially available from Novell or Microsoft. Thenetwork 274 may be implemented as an intranet, if desired. A computer272 connected to the network 274 may be used to obtain information froma business office device 278 and generate reports such as reportsshowing problems that occurred in various machines connected to thenetwork, and a monthly usage report of the devices connected to thenetwork 274. In this embodiment, a computer 276 is connected between thebusiness office device 278 and the network 274. This computer receivescommunications from the network and forwards the appropriate commands ordata, or any other information, to the business office device 278.

Communication between the business office device 278 and the computer276 may be accomplished using wire-based or wireless methods including,but not limited to, radio frequency connections, electrical connections,and light connections (e.g., an infrared connection, or a fiber opticsconnection). Similarly, each of the various networks and intranetsillustrated in FIG. 5 may be established using any desired mannerincluding through the establishment of wireless networks such as radiofrequency networks. The wireless communication described herein may beestablished using spread spectrum techniques including techniques whichuse a spreading code and frequency hopping techniques such as thefrequency hopping wireless technique disclosed in the BluetoothSpecification (available at the World Wide Web site www.bluetooth.com),which is incorporated herein by reference.

Another sub-system illustrated in FIG. 5 includes a firewall 50-4, anintranet 260-4, a computer 282 connected thereto, a business officeappliance 285 and a copier 286. The computer 282 may be used to generatereports and request diagnostic or control procedures. These diagnosticand control procedures may be performed with respect to the businessoffice appliance 285 and the copier 286 or any of the other devicesillustrated in or used with FIG. 5. While FIG. 5 illustrates a pluralityof firewalls, the firewalls are preferable, but optional equipment, andtherefore, the invention may be operated without the use of firewalls,if desired. For the monitoring and controlling of the networkedequipment, any computers (266, 272, or 282) can be used instead of 254.In addition, any computer may access 254 to retrieve necessary deviceinformation or usage information through the web.

FIG. 6A illustrates a device/appliance 300 connected to a typical e-mailexchange system, which includes components 302, 304, 306, 308, 310, 312,314, 316, and 318, which may be implemented in a conventional manner,and are adapted from FIG. 28.1 of Stevens, above. A computer interface302 interfaces with any of the application units or devices/appliances300 described herein. While FIG. 6A illustrates that thedevice/appliance 300 is the sender, the sending and receiving functionsmay be reversed in FIG. 6A. Furthermore, if desired, the user may notneed to interface with the device/appliance 300 at all. The computerinterface 302 then interacts with a mail agent 304. Popular mail agentfor Unix includes Berkeley Mail. Mail agents for the Windows family ofoperating systems include Microsoft Outlook and Microsoft OutlookExpress. At the request of the computer interface 302, the mail agent304 creates e-mail messages to be sent and, if desired, places thesemessages to be sent in a queue 306. The mail to be sent is forwarded toa Message Transfer Agent (MTA) 308. A common MTA for Unix systems isSendmail. Typically, the message transfer agents 308 and 312 exchangecommunications using a TCP/IP connection 310. Notably, the communicationbetween the message transfer agents 308 and 312 may occur over any sizenetwork (e.g., WAN or LAN). Further, the message transfer agents 308 and312 may use any communication protocol. In one embodiment the presentinvention, elements 302 and 304 of FIG. 6A reside in the library tomonitor the usage of the application unit.

From the message transfer agent 312, e-mail messages are stored in usermailboxes 314, which are transferred to the mail agent 316 andultimately transmitted to the user at a terminal 318 which functions asa receiving terminal.

This “store-and-forward” process relieves the sending mail agent 304from having to wait until a direct connection is established with themail recipient. Because of network delays, the communication couldrequire a substantial amount of time during which the application wouldbe unresponsive. Such delays in responsiveness may generally beunacceptable to users of the application unit. By using e-mail as thestore-and-forward process, retransmission attempts after failures occurautomatically for a fixed period of time (e.g., three days). In analternate embodiment, the application can avoid waiting by passingcommunicating requests to one or more separate threads. Those threadscan then control communication with the receiving terminal 318 while theapplication begins responding to the user interface again. In yetanother embodiment in which a user wishes to have communicationcompleted before continuing, direct communication with the receivingterminal is used. Such direct communication can utilize any protocol notblocked by a firewall between the sending and receiving terminals.Examples of such protocols include Telnet, File Transfer Protocol (FTP),and Hyper Text Transfer Protocol (HTTP).

Public WANs, such as the Internet, are generally not considered to besecure. Therefore, if it is desired to keep messages confidential,messages transmitted over the public WANs (and multi-company privateWANs) can be encrypted. Encryption mechanisms are known and commerciallyavailable and may be used with the present invention. For example, a C++library function, crypt( ), is available from Sun Microsystems for usewith the Unix operating system. Encryption and decryption softwarepackages are known and commercially available and may also be used withthis invention. One such package is PGP available from PGP Corporation.

As an alternative to the general structure of FIG. 6A, a single computerthat functions as the computer interface 302, the mail agent 304, themail queue 306, and the message transfer agent 308 may be used. Asillustrated in FIG. 6B, the device/appliance 300 is connected to acomputer 301, which includes the message transfer agent 308.

A further alternative structure is shown in FIG. 6C in which the messagetransfer agent 308 is formed as part of the device/appliance 300.Further, the message transfer agent 308 is connected to the messagetransfer agent 312 by a TCP/IP connection 310. In the embodiment of FIG.6C, the device/appliance 300 is directly connected to the TCP/IPconnection 310 with an e-mail capability. One use of the embodiment ofFIG. 6C includes using a facsimile machine with an e-mail capability(e.g., as defined in RFC 2305 (a simple mode of facsimile using Internetmail)) as the device/appliance 300. Many recent printers that can beconnected to a network have the capability to send e-mails that reportvarious state information.

FIG. 6D illustrates a system in which a device/appliance 300 does not byitself have the capability to directly receive e-mail, but has aconnection 310 to a mail server/POP3 server including a message transferagent 308 and a mail box 314 so that the device/appliance 300 uses thePOP3 protocol to retrieve received mail from the mail server.

FIG. 7 illustrates an alternative implementation of transferring mailand is adapted from FIG. 28.3 of Stevens referenced previously. FIG. 7illustrates an electronic mail system having a relay system at each end.The arrangement of FIG. 7 allows one system at an organization to act asa mail hub. In FIG. 7, there are four MTAs connected between the twomail agents 304 and 316. These MTAs include local MTA 322A, relay MTA328A, relay MTA 328B, and local MTA 322D. The most common protocol usedfor mail messages is SMTP (Simple Mail Transfer Protocol) which may beused with this invention, although any desired mail protocol may beutilized. In FIG. 7, 320 designates a sending host which includes thecomputer interface 302, the mail agent 304, and the local MTA 322A. Thedevice/appliance 300 is connected to, or alternatively included within,the sending host 320. As another case, the device/appliance 300 and host320 can be in one machine where the host capability is built into thedevice/appliance 300. Other local MTAs 322B, 322C, 322E, and 322F mayalso be included. Mail to be transmitted and received may be queued in aqueue of mail 306B of the relay MTA 328A. The messages are transferredacross the TCP/IP connection 310 (e.g., an Internet connection or aconnection across any other type of network).

The transmitted messages are received by the relay MTA 328B and ifdesired, stored in a queue of mail 306C. The mail is then forwarded tothe local MTA 322D of a receiving host 342. The mail may be placed inone or more of the user mailboxes 314 and subsequently forwarded to themail agent 316, and finally forwarded to the user at a terminal 318. Ifdesired, the mail may be directly forwarded to the terminal without userinteraction.

The various computers used in the present invention, including thecomputers 266 and 276 of FIG. 5, may be implemented as illustrated inFIG. 8. Further, any other computer used in this invention may beimplemented in a similar manner to the computer illustrated in FIG. 8,if desired, including the service machine 254, computer 272, andcomputer 282 of FIG. 5. However, not every element illustrated in FIG. 8is required in each of those computers.

In FIG. 8, the computer 360 includes a CPU 362 which may be implementedas any type of processor including commercially availablemicroprocessors from companies such as Intel, AMD, Motorola, Hitachi andNEC. There is a working memory such as a RAM 364, and a wirelessinterface 366 that communicates with a wireless device 368. Thecommunication between the interface 366 and device 368 may use anywireless medium (e.g., radio waves or light waves). The radio waves maybe implemented using a spread spectrum technique such as Code DivisionMultiple Access (CDMA) communication or using a frequency hoppingtechnique such as that disclosed in the Bluetooth specification.

Computer 360 includes a ROM 370 and a flash memory 371, although anyother type of non-volatile memory (e.g., Erasable Programmable ROM, oran EEPROM) may be used in addition to or in place of the flash memory371. An input controller 372 has connected thereto a keyboard 374 and amouse 376. There is a serial interface 378 connected to a serial device380. Additionally, a parallel interface 382 is connected to a paralleldevice 384, a universal serial bus (USB) interface 386 is connected to auniversal serial bus device 388, and also there is an IEEE 1394 device400, commonly referred to as a fire wire device, connected to an IEEE1394 interface 398. A system bus 390 connects the various elements ofthe computer 360. A disk controller 396 may be connected to a floppydisk drive 394 and a hard disk drive 392. Also, the disk controller 396may be connected to a CD/DVD drive. A communication controller 406allows the computer 360 to communicate with other computers (e.g., bysending e-mail messages) over a network 404. An I/O (Input/Output)controller 408 is connected to a local printer 410 and a hard disk 412,for example using a SCSI (Small Computer System Interface) bus. There isalso a display controller 416 connected to a CRT (Cathode Ray Tube) 414,although any other type of display may be used including a liquidcrystal display, a light emitting diode display, a plasma display, etc.

Referring now to FIG. 9, there is shown a schematic representation ofthe overall system 900 in accordance with an exemplary embodiment of thepresent invention. System 900 is shown to include a plurality ofdevices, for example, a laser printer 908, a scanner 910, a networkdevice 912, and a multi-function machine 914, all connected to a network100. The plurality of devices are generally referred to herein as“monitored devices.” The system 900 also includes aworkstation/monitoring system 902 (hereinafter referred to as acontroller 902), connected to the network 100 for monitoring andcontrolling the monitored devices 908, 910, 912, and 914. Each of themonitored devices 908, 910, 912, and 914 are given a unique address. Forexample, an IP address assigned to a device serves as a unique addressfor the device. Thus, a user at controller 902 is able to access arespective device among the monitored devices 908-914 by accessing theunique IP address assigned to the respective monitored device. It willbe appreciated that the present invention is not limited to using IPaddresses to uniquely identify devices connected to a network.

The controller 902, upon accessing a device among the monitored devices908-914, obtains various information through SNMP or/and HTTP protocols.Such information includes detailed information about the operationalstatus of the device including troubleshooting information. For example,controller 902 accesses and obtains the jam location of a particulardevice and sends a message to the person in charge of the device toclear the jam. The operational status/details of the laser printer 908include such details as toner level, indication of paper jam, quantityof print paper in printer trays, etc.

It will be appreciated that the controller 902 may be either physicallyconnected or wirelessly coupled to the network 100. For example, apersonal digital assistant (PDA) 920 or a laptop computer 922, shown tobe wirelessly coupled to the network 100, may also be used as acontroller 902. An access point 924 acts as an interface to enablewireless communications between the network 100 and PDA 922 or laptopcomputer 922. Henceforth, the present invention will be described withthe assumption that the controller 902 will be controlling andmonitoring the status of the monitored devices connected to the network.

The network 100 facilitates communication between the controller 902 andthe monitored devices 908-914 to enable monitoring and control of suchmonitored devices. The number of devices that are connected to thenetwork is not limiting of the present invention. It will be appreciatedthat the network 100 may be a local area network (LAN) or a wide areanetwork (WAN). Likewise, the monitored devices 908, 910, 912, and 914are shown to be merely exemplary.

The controller 902 is communicatively coupled to a storage device 904and a database 906. The storage device 904 includes a hard disk, opticaldisk, and/or an external disk drive. The database 906 is communicativelylinked to the storage device 904, and includes a Relational DatabaseManagement System (RDBMS) for easy search and retrieval of data storedin the storage device 904. The storage device 904 preferably storesdetailed information about each of the monitored devices 908-914. Forexample, detailed information, such as the make, model, and variousfunctions and trouble-shooting details of the laser printer 908 arestored in the storage device 904. Also, deviation values about theoperational status of the laser printer compared to predeterminedreference values may also be stored in the storage device 904. Althoughthe database 906 and the storage device 904 are described to becommunicatively coupled to the controller 902, it will be appreciatedthat the controller 902 may be built with the storage device and thedatabase installed therein. In such a case, the storage device 906 andthe database 904 would be depicted as being internal to the controller902.

The controller 902 is installed with software in order to facilitatemonitoring and control of the plurality, of devices 908-914. SimpleNetwork Management Protocol (SNMP), File Transfer Protocol (FTP) andHyper Text Transfer Protocol (HTTP) are used by the controller 902 formonitoring the plurality of devices 908-914 and the data received fromthe plurality of devices 908-914 is presented in the form of ASN.1Binary format or HTML or XML formats, as shown in 950.

Although FIG. 9 illustrates only the imaging devices, the network forcommunicating information between the monitoring device and theplurality of monitored devices may include the home network where theappliances and meters are connected to the network. It will beappreciated that data collected by the controller/workstation 902 can besent through e-mail, FTP, or any other communication protocol means to aremote device for further processing. Though the monitoring station 902,PDA 920, or the laptop 922 can be the controller that collects the dataand stores the data or sends the data through a communication protocol,it will be appreciated that the controller can be any of the devicesconnected to the network. Any of the network devices (e.g. printers) cancontain the monitoring system capable of monitoring the status of otherdevices in the network, storing the collected data and/or sending thecollected data through any other communication protocol means (e.g.,e-mail, FTP). The Xerox DocuPrint 4025 and HP LaserJet 9000 are bothcapable of sending e-mail.

The monitoring station 902 can send the collected information to aremote location by e-mail via SMTP or other protocol. As shown in FIG.9, the monitoring station 902 sends the information in an e-mail viaSMTP server 926 to a remote location or remote network. The remotelocation has a POP3 server 930 to receive the email. A workstation 940communicates with the POP3 server 930 to retrieve the email containingthe status information. The workstation 940 may store the statusinformation in a database 960. Email allows the information to be easilytransmitted to a remote location. The information may be in the emailmessage or in an attachment. The information may be encoded to providesecure transmission of the data. Other protocols such as FTP, HTTP, orweb service can be used to transmit the information to a remotelocation.

Monitoring System Architecture

FIG. 10 illustrates a monitoring system 1000 (and associated interfacefunctions) used in the monitoring of data associated with remote devicesaccording to an exemplary embodiment of the present invention. Themonitoring system 1000 includes the software module MonitorService 1004,which is a computer resident program such as Service in NT or Windows2000, and Daemon in Unix. In a preferred embodiment, the monitoringsystem is implemented using an objected-oriented software environment.Also included in the monitoring system 1000 are a Timer module 1002 andMonitor module 1006. Timer module 1002 and Monitor module 1006 arelibrary functions to be called by the MonitorService module 1004. Forexample, MonitorService 1004 initializes the Timer module 1002 bycalling the InitTimer 1003 function and obtains delay and actionparameters by calling obtainDelayAndAction (int &, int &) function. Theinit( ) function is also called by the MonitorService module 1004 toinitialize various modules in the Monitor module 1006, as illustratedlater. The init( ) function can be used to obtain the IP address andparameter value assigned to a monitored device through an externalsource containing IP addresses, parameter names and values collectedthrough known methods. The Monitor module 1006 is communicativelycoupled to a support database 1024 and to a monitor database 1014, whichare described in more detail below.

Once the IP address of a monitored device is obtained, the IP address isused by the monitoring system to contact the monitored device to obtaininformation such as, manufacturer (vendor) and model information. Someof the functions executed by the monitoring system 1000 include:

void initTimer(void)

This function initializes the Timer. In particular, this functiontriggers the Timer object to get the timing information from theregistry.

void obtainDelayAndAction(int & out_nDelay, int & out_nAction)

This function returns the delay time in seconds for the Sleep function(need to multiply 1000) and the action indicator. The action indicatoris defined as follows: 0=event checking; 1=sending the monitored data;and 2=monitoring and storing the data into the local database.

int init(void)

This function initializes the Monitor. In addition, it creates thedevices to be monitored. The return int is the error code in which zerois defined as no error.

int monitorStatus(int in_nAction)

This function monitors the preset information. The return int is theerror code in which zero is defined as no error.

int end(void)

This function cleans up the Monitor before closing the objects. Thereturn int is the error code in which zero is defined as no error.

Monitor Module

FIG. 11 shows the structural details of the Monitor module 1006,including the various software sub-modules, and the calling functionsbetween the sub-modules of the Monitor module 1006. The Monitor module1006 includes a Common module 1101 that contains classes used by manymodules, a MonitorManager module 1102 that manages the other sub-modules(including the DeviceODBC module 1104, the Device module 1110, and theHWaccess module 1116) to complete the tasks defined by interfacefunctions as illustrated in FIG. 10. Specifically, the DeviceODBC module1104 is accessed in order to access external device information throughthe standard interface. The HWaccess module 1116 obtains vendor, model,unique ID, and status information from the monitored devices using aselected communication protocol from among a plurality of communicationprotocols (e.g., HTTP, SNMP, and FTP). Each of the Monitor softwaremodules will be described in more detail below.

The following is a partial listing and description of the interfacesamong the Monitor modules discussed above. For example, some modules mayneed to have “init” functions or additional functions in order to obtainthe information in convenient formats.

void updateConfig(std::map<infoType, std::string> &)

Before this function is called, the calling function is preferred not toreplace the vendor and model entries if obtain functions return a nullstring. This function updates the device information database of thecurrent record in the DeviceODBC 1104. This function is most efficientwhen the ObtainConfig below is called initially. First, this functionchecks if the IP address is the same at the DeviceODBC 1104. If the IPaddress fields are not the same, the record with the correct IP addressis obtained from the database. Then, the other fields are copied and therecord is updated.

bool obtainConfig(std::map<infoType, std::string> &,std::map<std::string, std::vector<SParameter>> &)

This function obtains the map from DeviceODBC 1104 for the deviceinformation in the given format and the map of protocols and associatedparameters. The function returns true if there is data returned, falseif there is no more data.

bool saveStatus(std::map<infoType, std::string> &)

This function saves the status information into the DeviceODBC 1104. Thefunction returns true when saving is successful, false otherwise.

CDevice * createDevice(const std::string & in_sIP, CHWaccess &in_HWaccess, std::map<std::string, std::vector<SParameter>> &in_ProtocolParameters)

This function creates the device based upon in_sIP andin_ProtocolParameters. The created device is connected to the hardwarethrough CHWaccess. If the device can not be created, the functionreturns 0. Therefore, the calling object should check if the returnobject pointer is 0 or not.

bool canAccessHW(void)

This function returns true when the hardware can be accessed through thenetwork, false otherwise.

bool getVendor(std::string & out_sVendor)

This function returns the vendor name. If the device is not supported bythe system, but it can be accessed through one of the protocols, thestring shall contain “GENERIC.” If the error is detected in the process,the function returns false with null string. Otherwise, the functionreturns true.

bool getModel(std::string & out_sModel)

This function gets the model of the device. If the model is obtained,the function returns true. If the error is detected in the process, thefunction returns false with null string.

bool getUniqueID(std::string & out_sUniqueID)

This function returns the unique ID of the device. If the Unique ID isobtained, the function returns true. If the error is detected in theprocess, the function returns false with null string.

bool obtainStatus(map<infoType, std::string> & out_StatusMap)

This function returns the status map. The function returns true when thestatus is returned, false when status could not be obtained. Note thatthis function returns the different maps from the HWaccess and Devicemodules. In the Device module, event status information is added to themap returned from HWaccess and is cleared.

enum checkEventStatus(void)

This function triggers to obtain the event of the network device. Theenum type and values should be defined in the classes. The enum valuesshould include values eNoEventSinceClearAndNoEventDetected,eNoEventSinceClearAndEventDetected, eEventSinceClearAndNoEventDetected,eEventSinceClearAndEventDetected.

bool obtainEventStatus(std::map<infoType, std::string> &out_EventStatusMap)

This function obtains event status information. The function returnstrue when the status is returned, false when status could not beobtained.

void clearEventStatus(void)

This function clears the event status accumulated since the lastobtainStatus function call or clearEventStatus.

void initBegin(void)

This function starts the initialization process through HWaccess, inparticular, to create the software device objects.

void initEnd(void)

This function ends the initialization process through HWaccesssignifying that the device object creation is finished.

bool canAccessIP(const std::string & in_sIP, std::map<std::string,std::vector<SParameter>> & in_ProtocolParameters)

This function returns true when the device can be accessed at the IPaddress, false otherwise.

bool obtainVendor(std::string & out_sVendor, std::map<std::string,std::vector<SParameter>> & in Out_ProtocolParameters, const std::string& in_sIP)

This function obtains the Vendor. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the in Out_ProtocolParameters.

bool obtainModel(std::string & out_sModelName, std::map<std::string,std::vector<SParameter>> & in Out_ProtocolParameters, const std::string& in_sIP)

This function obtains the Model name. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined, and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the in Out_ProtocolParameters.

bool obtainUniqueID(std::string & out_sUniqueID, std::map<std::string,std::vector<SParameter>> & in Out_ProtocolParameters, const std::string& in_sIP)

This function obtains the Unique ID. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the in Out_ProtocolParameters.

EerrorCode obtainEventStatus(std::map<infoType, std::string> &out_StatusMap, const std::string & in_sIP, std::map<std::string,std::vector<SParameter>> & in_ProtocolParameters)

This function obtains the event status. The EerrorCode is defined below.

bool obtainStatus(std::map<infoType, std::string> & out_StatusMap, conststd::string & in_sIP, const std::string & in_sVendor, const std::string& in_sModel, std::map<std::string, std::vector<SParameter>> &in_ProtocolParameters)

This function obtains the status of the device. The function returnstrue if the operation is successful, false with the empty map otherwise.

FIG. 12 shows the sequence of the init( ) function to describe thecalling sequence of Monitor module 1006 as illustrated in FIG. 10. TheMonitorManager 1102 initializes the HWaccess module 1116 to start theinitialization function. Subsequently, the MonitorManager 1102 obtainsinformation about a monitored device and uses an IP address assigned tothe monitored device to communicate with the monitored device. TheMonitorManager 1102 accesses DeviceODBC 1104 to obtain configurationinformation of the monitored device. The configuration informationreturned to the MonitorManager 1102 includes, for example, an IP addressof the monitored device, parameter names and associated values for eachprotocol, and vendor/manufacturer and model information of the monitoreddevice. Once the IP address is obtained, the MonitorManager 1102 setsthe IP address, parameter names and associated values for each protocol,to create a software object for the device in the Device Module 1110.When the device software object is successfully created, the HWaccessmodule 1116 is used to obtain Vendor, Model, and Unique ID from themonitored device to be stored in the created device software object.

Once the vendor, model information, and unique ID are obtained from thedevice software object, the MonitorManager 1102 updates the database(for example, DeviceODBC 1104) with information received from themonitored device. Although FIG. 12 shows one device, the steps fromobtainConfig to updateConfig are repeated to cover all the devicesspecified in the external source. In addition, each protocol specifiedin FIGS. 18, 19, 20, and 22 are initialized. The database tablescorresponding to ODBC in FIGS. 17, 18, 19, 20, and 21 are accessed andnecessary information for accessed devices are transferred from theexternal storage to the internal data structure so that the statusinformation collection from the accessed devices is faster.

FIG. 13 shows the sequence of the status monitor function to determinethe status of a monitored device by the MonitorManager module 1102, asillustrated in FIG. 11. When the obtainStatus function is issued fromDevice to HWaccess, the CHWaccess class in turn issues an obtainStatusfunction call to each protocol described in FIG. 22 through the abstractclass, with different parameters, as described below. Each protocolmodule has already cached information necessary to extract the statusinformation from the monitored devices, which have already been accessedonce during the initialization time described in FIG. 12. Therefore, thestatus information can be quickly extracted from the monitored deviceswithout accessing the external source during the status monitoring. Thisprocess is repeated over all the monitored devices stored in the vectoras shown in FIG. 14.

Referring to FIG. 14, there is shown a vector 1500 having reference tothe devices created within the Device Module 1110 of FIG. 11 and used bythe MonitorManager 1102, as illustrated in FIGS. 12 and 13.MonitorManager 1102 stores device pointers, such as for example, Pointerto CDevice Object 1502, and Pointer to CDevice Object 1504 createdwithin the Device Module 1110, in the vector. The vector sequence isiterated to obtain the status of a monitored device. Polling ofmonitored devices is performed over the device object by issuing anobtainStatus command. Once the status of each of the software objects isobtained, such status is updated through the DeviceODBC 1104. The statusmonitor sequence was described above at FIG. 13, and will not berepeated herein.

The DeviceInfo structure shown in Table I illustrates the informationregarding one exemplary monitored device. The DeviceInfo structureincludes the e-mail address of the contact person, in addition to thetelephone number. Table 1 is an example of information, and not all theelements in the table are required. Also, any useful information relatedto a monitored device can be added in the database and the DeviceInfostructure.

TABLE 1 Type Name Description std::string m_sVendor A stringrepresenting the vendor of the network printer. std::string m_sModel Astring representing the model of the network printer. std::stringm_sUniqueID A string representing the Unique ID of the network printer.This ID may be a serial number or MAC Address or any unique IDobtainable from the network printer. std::string m_sIPAddress A stringrepresenting the IP address of the network printer. std::stringm_sCompanyName A string representing the name of the company which ownsthe network printer. std::string m_sStreet A string representing thestreet address of the company. std::string m_sCity A string representingthe city where the company is located. std::string m_sState A stringrepresenting the state where the company is located. std::stringm_sZipCode A string representing the zip code of the company.std::string m_sLocation A string representing the location of thenetwork printer within the company. std::string m_sContactPerson Astring representing the name of the contact person responsible for thenetwork printer. std::string m_sPhoneNumber A string representing thephone number of the contact person. std::string m_sEMailAddress A stringrepresenting the e-mail address of the contact person.Monitor Database

FIG. 17 illustrates the organization of the monitor database, whichincludes the device information for each monitored device (see alsoTable I). As shown in FIG. 17, a set of parameters, one set for eachcommunication protocol (e.g., SNMP, HTTP, and FTP), is associated withthe device information DeviceInfo 1902 for each monitored device.Moreover, each set of parameters for a particular protocol (e.g., SNMP1908, HTTP 1910, and FTP 1912) is organized as a list of parameter nameand value pairs, e.g., sPar1Name and sPar1Value. Note that the number ofparameters for each protocol may be shorter or longer than the numbershown in FIG. 17. For example, a username and password may be stored asFTP parameters, while a community name and a password may be stored asSNMP parameters for a given monitored device. As shown in FIG. 17, themonitor database also includes information related to the DeviceHistory1904, which contains the status information of the monitored devices,and the EnumCorrespondence 1906.

FIG. 15 illustrates the SParameter data structure 1700 used to pass theparameters used by the various communication protocols. SParameterincludes two fields: m_sParName 1702 and m_sParValue 1704, whichrepresent the name and value of the parameter, respectively.

FIG. 16 illustrates the map structure 1800 used to pass a vector ofparameters for each protocol obtained from the monitor database to asoftware object associated with each monitored device. The map structure1800 associates each protocol/key field 1802, 1804, and 1806, with acorresponding vector of parameters 1808, 1810, and 1812, respectively,arranged according to the SParameter format shown in FIG. 15. Forexample, for the SNMP protocol 1802, the vector of parameters 1808 mayinclude a list of parameter name, parameter value pairs that are used toaccess the monitored device with the SNMP protocol. For example, theSNMP parameter names stored in the vector 1808 might include “CommunityName” and “Password”, together with the corresponding parameter values.Note, however, that the organization of the map structure 1800 allowsfor any number of protocols and associated parameter vectors, and is notlimited to the SNMP, HTTP, and FTP protocols shown in FIG. 16.

Support Database

FIGS. 18-20 illustrate the organization of the support database 1024shown in FIG. 10. The support database, which includes informationnecessary to extract status information from each monitored device, isorganized by communication protocol. Moreover, the support databasecontains information for determining which protocols are supported by agiven vendor and model. For example, FIG. 18, which illustrates theorganization of the support database for SNMP-related supportinformation used to extract information from a monitored device,includes SNMPVendor 2002, SNMPComVendorStatus 2004, EnumCorrespondence2006, and SNMPVendorModelStatus 2008 data structures. A given datastructure in the support database may include parameters that uniquelyidentify the type of status information to be extracted, along withparameters that control the extraction. For example, theSNMPComVendorStatus data structure 2004 include an nENUM field 2009,which identifies the type of information to be extracted (e.g., tonerlevel), and an nRelativePriority field 2010, which indicates the weightor importance of the extracted information relative to other protocols.Thus, if the same information may be extracted from the monitored deviceusing more than one protocol, the nRelativePriority value gives arelative indication of which protocol's extracted value should be used.For example, if HTTP is only able to extract information indicatingwhether the toner level is “high” or “low” while the SNMP protocol isable to extract the percentage level of toner remaining, the prioritylevel for the toner level for SNMP would be higher than thecorresponding value for HTTP. In addition, the support database mayprovide default priority values for an entire protocol. In oneembodiment, the SNMP protocol is given a priority value of 10,000 in asystem in which protocol values may range from 0 to 32,000.

FIGS. 19 and 20 illustrate the data structures included in the HTTP andFTP portions of the support database 1024 and includes data structuresanalogous to the data structures described above with regard to FIG. 18.The EnumCorrespondence data structure shown in FIGS. 18-20 is shared bythe data structures for all of the protocols in the support database andis the same data structure shown in FIG. 17.

FIG. 19 shows the tables of the support database used by the HTTPprotocol. The tables HTTPVendorModelWebPage and HTTPWebPageModeldetermine which vendor and model are supported by the HTTP protocol. Thetwo tables also contain information used to extract the model name fromthe web page of the device. The table HTTPVendorModelUniqueID containsinformation about the web page of a device that contains the unique IDfor a given vendor and model. The table HTTPVendorModelStatusWebPagecontains information about the web pages of a device that containsstatus information for a given vendor and model. The tablesHTTPWebPageExtractFromLine and HTTPWebPagePreconditions containinformation used to locate and extract the unique ID or statusinformation from a web page of a device.

FIG. 20 shows data structures containing support information used toextract information from FTP files of a monitored device.

Exemplary enum types used by the present invention is the infoTypedefined below. (The enum types are merely exemplary and therefore shouldnot be construed as limiting the present invention.)

infoType (typedef int infoType)

This section describes the definition of the infoType (int). The valuerange 0 through 99 is assigned to the data type. The value range 100 to499 is assigned to Device Information. The value range 500 to 1999 isassigned to the common parameters including standard MIB parameters. Therange 2000 to 3999 is assigned to Ricoh-specific information. The range4000 to 4999 is assigned to Xerox. The range 5000 to 5999 is assigned toLexmark. The range 6000 to 6999 is assigned to HP. 7000 and highervalues are assigned to Brother, Samsung, Kyocera Mita, Dell, andKonica-Minolta. The values are defined as follows:

infoType {eNotDefine=0, eDeviceInformation=1, eStatusInformation=2,eVendor=100, eModel, eUniqueID, eIPAddress, eCompanyName, eStreet,eCity, eState, eZipCode, eLocation, eContactPerson, ePhoneNumber,eEMailAddress, eDateTime=500, eHrDeviceErrors, eLowPaper, eNoPaper,eLowToner, eNoToner, eDoorOpen, ejammed, eOffline, eServiceRequested,ePrtGeneralConfigChanges=600, ePrtLifeCount, ePrtAlertDesc1,ePrtAlertDesc2, ePrtAlertDesc3, ePrtAlertDesc4, ePrtAlertDesc5,eBlack=700, eMagenta, eCyan, eYellow, eTonerCollector=800,eBlackDeveloper=810, eColorDeveloper, eFuser=820, eDrum=830,eTransfer=840, eMaintenanceKit=850, eOilKit=860, eStationInfo1=901,eStationInfo2, eStationInfo3, eStationInfo4, eStationInfo5,eRicohEngineCounterTotal=2000, eRicohEngineCounterPrinter,eRicohEngineCounterFax, eRicohEngineCounterCopier}.

EerrorCode

The following codes are merely exemplary, and more codes may be added tothe existing set. The range 0-99 is reserved. The range 100-199 is forSMTP, 200-299 is for POP3, 300-399 is for Socket, and 400-499 is forHTTP, and 500-599 is for FTP. Other ranges not specified may be definedby a user, if needed.

enum EerrorCode(eNoError=0, eUnknownError=1, eSomeError,eCompleteFailure, eSomeDeviceCreationError=20, eCreateDeviceError,eNoDeviceCreated, eObtainConfigError, eSaveStatusError,eObtainUniqueIDError, eObtainStatusError, eStartSendError,eSomeDataSendError, eCompleteDataSendFailure, eEndSendError,eSendHeloCommandFailed=100, eSendMailCommandFailed,eSendRcptCommandFailed, eSendDataCommandFailed, eSendDataFailed,eSendQuitCommandFailed, eSendUserCommandFailed=200,eSendPassCommandFailed, eSendStatCommandFailed, eSendRetrCommandFailed,eSendDeleCommandFailed, eSendQuitPop3CommandFailed,eCreateSocketFailed=300, eConnectSocketFailed, eBadRequest=400,eUnauthorized, ePaymentRequired, eForbidden, eNotFound,eMethodNotAllowed, eNotAcceptable, eProxyAuthenticationRequired,eRequestTimeOut, eConflict, eGone, eLengthRequired, ePreconditionFailed,eRequestEntityTooLarge, eRequestURITooLarge, eUnsupportedMediaType,eRequestedRangeNotSatisfiable, eExpectationFailed,eInternalServerError=450, eNotImplemented, eBadGateway,eServiceUnavailable, eGatewayTimeOut, eHTTPVersionNotSupported,eMultipleChoices=480, eMovedPermanently, eFound, eSeeOther,eNotModified, eUseProxy, eTemporaryRedirect).

FIG. 21, shows the tables of the support database used to determine thenormalized vendor and model that the system supports. The tableNormalizedVendor contains the mapping of all vendor names to a commonvendor name that all protocols will use. The table NormalizedVendorModelcontains the mapping of all model names to a common model name that allprotocols will use and the mapping of the normalized vendor and model toan ID.

Abstract Classes in the HWaccess Module

FIG. 22 shows the package diagram for the HWaccess package. This packageis responsible for identifying the network devices to be monitored andobtaining information about the network devices using various networkprotocols (e.g. SNMP, HTTP, and FTP). The package contains the packagesHTTP 2302, SNMP 2304, FTP 2306, NormalizedVendorModelODBC 2312, and theclasses CHWaccess 2300, CAbsProtocol 2308, CRecordset 2310, andCNormalizedVendorModel 2314. The packages HTTP 2302, SNMP 2304, and FTP2306 implement the network protocols to access the network devices toobtain information from them. For example, the HTTP package 2302implement the HTTP protocol to access the web pages of the networkdevices to obtain information from the web pages. The class CHWaccess2300 manages all the protocol packages to obtain the necessaryinformation from the network devices. The class CAbsProtocol 2308 is anabstract class representing any protocol. This class provides theinterface between CHWaccess 2300 and the protocol packages. The classCAbsProtocol 2308 provides a set of common functions as shown in FIG. 22to CHWaccess 2300 in which all protocols will provide CHWaccess 2300 thenecessary information. The classes derived from CAbsProtocol 2308 asdescribed in later figures will provide the method for each of thefunctions for the appropriate protocols. The class CRecordset 2310 is aclass of the Microsoft Foundation Class that provides each of theprotocol package access to the database to obtain information aboutwhich vendor and model of network devices are supported and whatinformation to obtain from those network devices. The classCNormalizedVendorModel 2314 is a member of a namespace so that theobject for this class can be shared by all the protocol packages. Theclass 2314 contains information so that the protocols can obtain thenormalized vendor, normalized model, and ID for the vendor and model.The normalized vendor and model names provide a common name that allprotocols can use. The class 2314 obtains information about thenormalized vendor and model and ID from the support database through theNormalizedVendorModelODBC 2312 package. The 2312 package provides accessto tables in the support database to obtain the normalized vendor andmodel and ID.

Each of the protocol packages, HTTP 2302, SNMP 2304, and FTP 2306, asdescribed in FIG. 22, contain a class that manages the access to thenetwork device to obtain information from the device. The class isderived from the abstract class CAbsProtocol 2308 which provides for themethod of implementing the protocols to access information from thenetwork device. An abstract class only provides the interface functionsbut does not perform any process. The classes derived from the abstractclass provide the method to perform the process for the interfacefunctions. There can be many derived classes of the abstract class sothat the different derived classes can perform the process of theinterface function differently. From the design of the HWaccess package,a new protocol can be added to the system by adding a new package thatcontains a derived class of CAbsProtocol that manages the new package toaccess the network device using the new protocol. The abstract classallows for the future expansion of the system.

FIG. 23 shows the data structure that is used in the HWaccess package ofFIG. 22 to maintain all the protocols to access and to obtaininformation from the network devices. In FIG. 23, the data structure isa vector 500 of pointers to CAbsProtocol 2308. The class CHWaccess 2300will contain and use this data structure. Even though the vector 500will contain pointers to classes derived from CAbsProtocol 2308,CHWaccess 2300 will see the vector as containing pointers toCAbsProtocol 2308 and call the interface functions of CAbsProtocol 2308through the virtual function call mechanism. In actuality, CHWaccess2300 will call the interface functions of the derived classes ofCAbsProtocol 2308. For example, the pointer to the CAbsProtocol 502 inthe first entry in the vector may be a pointer to the derived classCSNMPProtocol, the pointer to the CAbsProtocol 504 in the second entryin the vector may be a pointer to the derived class CHTTPProtocol, andthe pointer to the CAbsProtocol 506 in the third entry in the vector maybe a pointer to the derived class CFTPProtocol. So when CHWaccess 2300calls the interface functions of CAbsProtocol 2308 in the vector, it isactually calling the interface functions of CSNMPProtocol,CHTTPProtocol, and CFTPProtocol. The use of the abstract classCAbsProtocol 2308 in the vector 500 allows any protocol to be used toaccess and obtain information from the network devices. The abstractclass CAbsProtocol 2308 hides the detail of what protocol is being used.

FIG. 24 is a sequence diagram that shows the initialization of theHWaccess package when init( ) of the Monitor package is called. TheCNormalizedVendorModel object is created and initialized so that allprotocol objects can obtain the normalized (or common) name and ID forthe vendor and model. All the protocol objects will be created andinitialized to access information from the devices to be monitored. Thecalling of the function initBegin( ) of CHWaccess will create theCNormalizedVendorModel object and will be accessible to all the protocolobjects. initBegin( ) of CNormalizedVendorModel is called to initializeits data structures with information about all the vendors and its'normalized vendors, all the models and its' normalized models and the IDfor the normalized vendor and model. Then all the protocol objects (allderived from CAbsProtocol) will be created in the createProtocols( )function. initBegin( ) of each protocol object will be called toinitialize its support information used to determine the vendor, model,and unique ID of the monitored devices. Before initEnd( ) of CHWaccessis called, functions of CHWaccess and the protocol objects will becalled to access the device and obtain and initialize vendor, model, andunique ID information of the device for all the protocols. By the timeinitEnd( ) of CHWaccess is called, each protocol object has all theinformation it needs to obtain the status information for the monitoreddevices which the protocol supports. initEnd( ) of each protocol objectwill clean up all the data structures it does not need after itsinitialization. initEnd( ) of CNormalizedVendorModel will clean up allthe data structures it contains before the CNormalizedVendorModel isdeleted.

FIG. 25 is a sequence diagram that shows canAccessIP( ) of the HWaccesspackage to determine if the device is accessible by any protocol.CHWaccess will call canAccessIP( ) of each protocol object until one ofthe protocol objects can access the device corresponding to the IPaddress. If none of the protocol objects can access the device,canAccessIP( ) of CHWaccess returns false and the device will not bemonitored.

FIG. 26 is a sequence diagram that shows the scenario for obtaining thevendor, model, and unique ID of the device from protocol objects andinitializing the other protocol objects with vendor and modelinformation. Once a protocol object obtains the vendor and modelinformation of the device, the protocol object obtains the normalizedvendor and model name of the device from the CNormalizedVendorModelobject and updates it support for the device so it can obtain statusinformation from the device. CNormalizedVendorModel uses the datastructures shown in FIG. 30 through 33 for returning the normalizedvendor and model name (and vendor model ID if needed). The otherprotocol objects will need to receive information about the vendor andmodel of the device so it can update its support for the device so itcan obtain status information from the device. CHWaccess will use asmany of the protocol objects as necessary to obtain the vendor, model,and unique ID of the device and initialize all the other protocolobjects with vendor and model information. CDevice (1110) object willkeep the normalized vendor, normalized model, and unique ID informationfor a given IP address of the device. In the sequence diagram, CHWaccesscalls obtainVendorModelUniqueID( ) of a protocol object and gets all theinformation from the protocol object. The protocol object obtains thenormalized vendor and model name and ID by callingobtainNormalizedVendorModelID( ) of CNormalizedVendorModel. CHWaccesswill then initialize all the other protocol objects with the normalizedvendor and model information by calling initWithVendorModel( ) of allthe other protocol objects. The protocol objects may callobtainIDForNormalizedVendorModel( ) of CNormalizedVendorModel if theprotocol objects needs to use the ID.

For obtaining the vendor, model, and unique ID for another device in thesequence diagram, CHWaccess calls obtainVendorModelUniqueID( ) of aprotocol object and may get only the vendor name. The protocol objectobtains the normalized vendor name by calling obtainNormalizedVendor( )of CNormalizedVendorModel. Then CHWaccess calls obtainModel( ) andobtainUniqueID( ) of another protocol object to obtain the model andunique ID. The protocol object will obtain the vendor, model, and uniqueID information from the device and will obtain the normalized vendor andmodel name and ID by calling obtainNormalizedVendorModelID( ) ofCNormalizedVendorModel. CHWaccess will then initialize all the otherprotocol objects with the normalized vendor and model information bycalling initWithVendorModel( ) of all the other protocol objects. Theprotocol objects may call obtainIDForNormalizedVendorModel( ) ofCNormalizedVendorModel if the protocol objects needs to use the ID.

FIG. 27 shows a flowchart describing how the Protocol Parameter Map 1800of FIG. 16 is updated to determine which protocols are used to obtainthe status information from a network device. The steps in FIG. 26 areperformed to obtain the vendor name and the model name of a networkdevice for a protocol. In step 3702, a check is made to determine if thenetwork device can be accessed using a protocol. The network device isaccessed through the protocol using the information in the map 1800. Ifthe network device cannot be accessed through the protocol, the protocolis removed from the protocol parameter map 1800 in step 3704 and theupdating of the map 1800 is completed in step 3714. If the networkdevice can be accessed through the protocol, then in step 3706 a checkis made to determine if the vendor of the network device can be obtainedusing the protocol. If the vendor cannot be obtained, then in step 3707a check is made if GENERIC vendor is supported by the protocol. Supportfor GENERIC vendor for a protocol means that a protocol can obtainstatus information that is common to all devices (common statusinformation) through some standard even if it cannot obtain or does notsupport the vendor of the devices. If GENERIC vendor is not supported bythe protocol, then the protocol is removed from the protocol parametermap 1800 in step 3704 and the updating of the map 1800 is completed instep 3714. If GENERIC vendor is supported by the protocol, then theprotocol remains in the protocol parameter map 1800 and the updating ofthe map is completed in step 3714. If the vendor can be obtained in step3706, then in step 3708 a check is made to determine if the vendor ofthe network device is supported. If the vendor is not supported by theprotocol, then in step 3707 a check is made if GENERIC vendor issupported by the protocol. The sequence of steps following step 3707 isdiscussed above.

If the vendor is supported by the protocol, then in step 3710 a check ismade to determine if the model of the network device can be obtainedusing the protocol. If the model cannot be obtained, then in step 3711 acheck is made if GENERIC model is supported by the protocol. Support forGENERIC model for a protocol means that a protocol can obtain statusinformation that is common to all devices of a vendor (vendor specificstatus information) even if it cannot obtain or does not support themodel of the devices. If GENERIC model is not supported by the protocol,then the protocol is removed from the protocol parameter map 1800 instep 3704 and the updating of the map 1800 is completed in step 3714. IfGENERIC model is supported by the protocol, then the protocol remains inthe protocol parameter map 1800 and the updating of the map is completedin step 3714. If the model can be obtained in step 3710, then in step3712 a check is made to determine if the model of the network device issupported. If the model is not supported by the protocol, then in step3711 a check is made if GENERIC model is supported by the protocol. Thesequence of steps following 3711 is discussed above. If the model issupported by the protocol, then the protocol can be used to obtainstatus information for the network device and the updating of theprotocol parameter map 1800 is completed in step 3714. If the vendor andmodel are not obtained or not supported, then the protocol is removedfrom the protocol parameter map 1800 and the protocol is not used toobtain status information. There are variations to the process shown inFIG. 27 depending on the protocol.

As discussed above, status information can be obtained by SNMP from thenetwork device even if the vendor and model are not obtained orsupported. As long as the network device supports SNMP and can beaccessed by SNMP, information can be obtained using the standardManagement Information Base (MIB) of the network device. In step 3702,if the network device cannot be accessed through SNMP, then the SNMPprotocol may be removed from the protocol parameter map 1800 in step3704. However, if the network device can be accessed through SNMP, thenthe SNMP protocol remains in the protocol parameter map 1800 whether ornot the vendor or model is obtained and supported. Network devices thatsupport SNMP provide a MIB so that the remote system can always obtaininformation from the devices. However, the type and number ofinformation that can be obtained from the network device depends upon ifthe vendor and model are obtained and supported. More information can beobtained from the network device by SNMP if the vendor and model areobtained and known. If the vendor and model cannot be obtained, SNMP isstill able to obtain information that all devices can provide, such asthe system description or the time the system has been running. SNMP canbe used to obtain information from the network device under the threeconditions: (1) vendor and model are supported, (2) vendor supported butmodel not supported, and (3) vendor and model are not supported. HTTPand FTP do not have the characteristics as SNMP. Where SNMP has astandard MIB that all network devices can follow so that information canbe obtained, web pages and FTP files will vary among network devices ofdifferent vendors and models. There is no standard for web pages and FTPfiles which network devices follow to obtain information.

FIG. 28 shows a flowchart describing the process of obtaining statusinformation about the network devices using all the protocols. After theprotocol objects have been initialized with information about the vendorand model of network devices it supports, the protocol objects can beused to obtain status information from the network devices. The protocolobjects contain information about how to obtain status information forgiven vendors and models using the data structures containinginformation from the support database of FIGS. 18, 19, and 20. Thevector of pointers to CAbsProtocol 2308 described in FIG. 22 is used toobtain the status information for all the protocol objects. The processof the flowchart will step through the vector once. In step 3122, aprotocol object is obtained from the vector of pointers to CAbsProtocol.The protocol object corresponds to one of the network protocols toaccess the network device (e.g. SNMP, HTTP, and FTP). In step 3124, acheck is done to see if there are any more protocol objects that can beobtained from the vector. This check is done by determining if the endof the vector has been reached. If no more protocol objects can beobtained, then the system is done in obtaining the status informationfrom the network device using all the protocol objects in step 3126. Ifthere is a protocol object obtained from the vector, then use theprotocol object to obtain the status information of the network devicein step 3128. After obtaining the status information using the protocolobject, obtain more status information using another protocol object bygoing back to step 3122.

FIG. 29 shows the data structure used to maintain the status informationobtained through the various protocols. It does not maintain informationabout which protocol was used to obtain the status information. The datastructure is a map 724. The key 726 to the map 724 is an infoType.infoType is a number representing a type of information. The value 728to the map 724 is a pair. The pair consists of a string and an integer.The string in the pair is the status information obtained from thenetwork device that corresponds to the infoType. The integer in the pairis the weight or priority of the status information as obtained from aprotocol. As an example, for the infoType of 700 that may represent thelevel of black toner in the printer cartridge, the pair may contain thestring “75%” and integer 10000. The string “75%” indicates that 75% ofthe toner remains in the cartridge and the integer 10000 is the weightor priority of the status information. CSNMPProtocol 2402, CHTTPProtocol2502, and CFTPProtocol 2602 adds status information that it obtains fromthe network devices to the map 724. If there is a same infoType alreadyin the map, the pair of values of higher priority is kept in the map.

FIG. 30 is a map structure attribute member, m_NormalizedVendorMap, ofthe class CNormalizedVendorModel that is in the HWaccess module of FIG.22. The map structure attribute member of FIG. 30 contains informationabout the vendors supported by the system and maps the vendor name tothe normalized vendor name. The key of the map is the various names ofvendors that the system supports and the value of the map is thenormalized vendor. The key will contain the names of vendors that thedifferent protocols may obtain since not all the protocols will obtainthe exact same name for a vendor. In addition, merger and acquisitionmay result in the different company names. The value will contain anormalized name for the different names of the vendor that all protocolscan use. This allows a mapping of different vendor names as obtained byvarious protocols to one unique vendor name. For example, the SNMPprotocol may obtain the vendor name hp from a device. The HTTP protocolmay obtain the vendor name Hewlett-Packard from the same device. Thenormalized vendor for the device that all protocols will use for thedevice will be HP. The map also serves the purpose of providing anormalized vendor name for vendor names of merged companies. All thedifferent vendors for the merged company will map to a single vendorname which may be one vendor name or a combination of the vendor names.For example, the HTTP protocol may obtain the vendor name Minolta from adevice. The SNMP protocol may obtain the vendor name QMS for the samedevice. The normalized vendor for the device which corresponds to mergedcompanies that all protocols will use for the device will beKonicaMinolta. This map is populated with information from the tables ofthe support database of FIG. 21.

FIG. 31 is a map structure attribute member, m_NormalizedModelMap, ofthe class CNormalizedVendorModel (2314) that is in the HWaccess moduleof FIG. 22. This map structure is used to obtain the normalized modelname after the normalized vendor name is obtained using the mapstructure shown in FIG. 30. The map structure attribute member of FIG.31 contains information about the models supported by the system andmaps the model name to the normalized model name. The key of the map isthe concatenation of the normalized vendor name and the various names ofmodels that the system supports with a separator (‘%’) between them. Thevalue of the map is the normalized model name. The key will contain thenames of models that the different protocols will obtain since not allthe protocols will obtain the exact same name for a model. The valuewill contain a name for the different names of the model that allprotocols will use and have in common. This allows a mapping ofdifferent model names as obtained by various protocols to one uniquemodel name. For example, the SNMP protocol may obtain the model name“CLP 550” from a model of a Samsung printer. The HTTP protocol mayobtain the model name “CLP-550” from the same printer. The normalizedmodel name for the device that all protocols will use for the devicewill be CLP550. This map is populated with information from the tablesof the support database of FIG. 21.

FIG. 32 is a map structure attribute member, m_VendorModelIDMap, of theclass CNormalizedVendorModel that is in the HWaccess module of FIG. 22.The map structure attribute member of FIG. 32 contains information aboutthe ID associated with the normalized vendor and model name. The key ofthe map is the concatenation of the normalized vendor name and thenormalized model name with a separator (‘%’) between them. The value ofthe map is a number for the vendor model ID. This ID uniquely identifiesthe vendor model. The protocols may use the ID. For example, the HTTPprotocol uses the vendor model ID in the map structure of FIG. 40 thatwill be used to obtain the unique ID of the device for a given vendorand model. The map, m_VendorModelIDMap, is populated with informationfrom the tables of the support database of FIG. 21.

FIG. 33 is a class diagram for the NormalizedVendorModelODBC package.This package interfaces with the support database to obtain informationto map vendor names with normalized vendor names, model names withnormalized model names, and vendor and model names with IDs. TheCNormalizedVendorModelODBC class 3300 is the interface for this packageand manages the other classes to obtain the appropriate information fromthe tables of the support database. The CXXXData classes 3306 and 3302,and their corresponding CXXXTable classes 3308 and 3304, provide accessto the XXX tables of the support database shown in FIG. 21 to obtaininformation from the tables.

FIG. 34 is a flowchart that describes the process of determining thenormalized vendor name and normalized model name from the vendor nameand model name obtained by a protocol from a device. The process ofobtaining the normalized vendor name and normalized model namecorresponds to calling the interface functions of CNormalizedVendorModelshown in FIG. 22. The process starts with step 3402, in which theprotocol obtains the vendor and model name from the device. The vendorand model name obtained corresponds to the names the protocol's knowwhich may or may not be the normalized names. In step 3404, from thevendor name obtained, determine if the vendor name exists in thenormalized vendor lookup table. This process is checking if the vendorname is one of the keys of the map m_NormalizedVendorMap of FIG. 30. Ifnot, then the process is complete without obtaining the normalizedvendor and model name. If it is one of the keys, the process proceeds tostep 3406. In step 3406, the value from the map corresponding to the keyfor the normalized vendor name is obtained. In step 3408, with thenormalized vendor name and the model name obtained by the protocol,create a string with the normalized vendor name and model name separatedby %. In step 3410, the string is used to check if the model name existsin the normalized model lookup table. This process is checking if thestring is one of the keys of the map m_NormalizedModelMap of FIG. 31. Ifnot, then the process is complete with only obtaining the normalizedvendor name. If it is one of the keys, the process proceeds to step3412. In step 3412, the value from the map corresponding to the key forthe normalized model name is obtained. The process is then complete withthe normalized vendor name and normalized model name obtained.

The flowchart of FIG. 34 is an example of a protocol obtaining thenormalized vendor and model. If the protocol needed the vendor model ID,then the process would include obtaining the ID from the mapm_VendorModelIDMap of FIG. 32 with the use of the normalized vendor andmodel name. All protocols may not need to obtain the normalizedinformation. Protocols will vary in the information it wants from theclass CNormalizedVendorModel so that the flowchart of FIG. 34 is one ofmany possible processes that a protocol will follow.

FIG. 35 is a package diagram for the HTTP package. This package supportsthe extraction of information from web pages of devices. The packageuses the abstract class CAbsProtocol described in FIG. 22 above. TheCHTTPProtocol class is derived from CAbsProtocol. CHTTPProtocol is theinterface for the HTTP package and manages the packages HTTPaccess andHTTPODBC described in FIGS. 37 and 38 below to obtain information fromthe devices. The HTTP package uses the class CNormalizedVendorModeldescribed in FIG. 22 above for information about normalized vendor name,normalized model name, and vendor model ID. The HTTP package containsand uses the structure SKeyValueInfo described in FIG. 36 below tolocate and extract information from the web page of a device. The dataelements of SKeyValueInfo are obtained from the tables of the databaseshown in FIG. 19.

FIG. 36 shows the structure SKeyValueInfo that is used in the HTTPpackage of FIG. 35 to locate and extract information from the web pages.m_infoType is a number representing the type of information. Forexample, an m_infoType value of 601 represents the total pages printedby the network device and an m_infoType value of 700 represents theblack toner level remaining. m_nRelativePriority represents the weightof the information that will be extracted by the HTTP protocol. Am_nRelativePriority that is higher than that of other protocolsindicates that the information extracted by the HTTP protocol is moreinformative and desirable. A m_nRelativePriority that is lower than thatof other protocols indicates that the information extracted by the HTTPprotocol should not be used if other protocols already obtain theinformation. The vector of sKey is a vector of strings that will be usedto locate the desired information from a web page. The strings will letthe HTTP protocol navigate to the line containing the desiredinformation. The strings are placed in the vector in a particular orderso that as each are searched for and found in the web page, the closerthe HTTP protocol is to the line containing the desired information.After the last string in the vector is identified in the line of the webpage, the next line shall contain the desired information. The strings,along with the sequence number to identify the last line before thetarget line, are obtained from HTTPWebPagePreconditions table in FIG.19. The strings, obtained from HTTPWebPageExtractFromLine in FIG. 19,m_sFrontDelete1, m_sFrontDelete2, and m_sBackDelete, are used to extractthe information from the line containing the desired information.m_sFrontDelete1 and m_sFrontDelete2 will be used to delete the stringsin front of the desired information and m_sBackDelete will be used todelete the string in back of the desired information.

FIG. 37 is a package diagram for the HTTPaccess package. This package isresponsible for initiating and closing an HTTP session with a networkdevice and to extract information from the web page of the device. Theclass CHTTPaccess is the interface for this package and manages otherclasses to perform the package's tasks. The class CHTTPSession initiatesand closes an HTTP session with a device and accesses the web page ofthe devices. The class CHTMLProcessor process the lines of a web page ofa device to locate and extract the desired information. The classCExtractValueFromLine processes a line of the web page containing thedesired information so as to extract the information. The classesCInternetSession, CHttpConnection, and CHttpFile are classes of theMicrosoft Foundation Classes (MFC) that are used by CHTTPSession toaccess the web pages of a device.

FIG. 38 is a package diagram for the HTTPODBC package. This packageinterfaces with the support database to obtain information used toextract the model name, unique identifier, and status information fromthe web pages of a device. The CHTTPODBC class 3800 is the interface forthis package and manages the other classes to obtain the appropriateinformation from the tables of the support database. The CHTTPXXXDataclasses 3802, 3806, 3810, 3814, 3818, and 3822 and their correspondingCHTTPXXXTable classes 3804, 3808, 3812, 3816, 3820, and 3824 provideaccess to the XXX tables of the support database shown in FIG. 19 toobtain information from the tables.

FIG. 39 is a map structure that is used in the HTTP package of FIG. 35to extract the model name from the web pages. The map structurem_VendorModelSearchMap is an attribute member of CHTTPProtocol. The keyto the map is a string for the normalized vendor name. The value to themap is a vector of pairs. The first element of the pair is a name of theweb page which would contain the model name and the second element ofthe pair is a vector of strings for all the model names that could befound in the web page. For a given vendor name, the map structure wouldcontain all the web pages that would contain model names for thedevices. Each web page would contain at least one model name that can befound in the web page. If a web page is accessible, then each line ofthe web page is searched to see if one of the model strings can befound. If one is found, then the vendor and model of the device isdiscovered. If the model cannot be found, then the vendor is known sinceits web page is accessible but the model is not supported. However, theHTTP protocol does not support obtaining status information from devicesif only the vendor name is known. The normalized vendor name is used inthe map rather than the vendor name that would be found in the web page.The reason is that if the web page is accessible, then that web page isassociated with the vendor so that the normalized vendor can be used.This map structure is populated with information from the supportdatabase. Description of how this map is used is provided in FIGS. 44 to46.

FIG. 40 is a map structure that is used in the HTTP package of FIG. 35to extract the unique ID from the web page of a device. The mapstructure m_UniqueIDSearchMap is an attribute member of CHTTPProtocol.The key to the map is an integer that is the vendor model ID. This IDcorresponds to the normalized vendor and normalized model of the mapm_VendorModelIDMap of FIG. 32. The value to the map is a pair. The firstelement in the pair is the name of the web page that will contain theunique ID. The second element in the pair is a vector of the structureSKeyValueInfo. The vector will only contain one SKeyValueInfo structuresince only one is needed to extract the unique ID from the web page.Once the vendor and model of the device is known, the unique ID isobtained using information from this map structure. This map structureis populated with information from the tables of FIG. 19 in the supportdatabase.

FIG. 41 is a map structure that is used in the HTTP package of FIG. 35to extract the status information from the web pages of all devices thatare monitored. The map structure m_VendorModelStatusMap is an attributemember of CHTTPProtocol. The key to the map is a string containing thenormalized vendor and normalized model name separated by %. The value tothe map is a vector of pairs. The first element in the pair is the nameof the web page that contains one or more status information. The secondelement in the pair is a vector of the structure SKeyValueInfo. Thevector will contain SKeyValueInfo structures to extract all the statusinformation from the web page. For a given vendor and model, the vectorwill contain pairs for all the web pages from which status informationcan be extracted. Once the vendor and model are determined for a device,information about obtaining status information from the device isobtained from the support database and added to the map structure.Description of how this map is used is provided in FIGS. 47 to 50.

FIG. 42 is a vector structure that is used in the HTTP package of FIG.35 to extract the status information from a web page of a device. Thevector structure m_ExtractionStateVector is an attribute member ofCHTMLProcessor. The vector structure is a vector of the structureSExtractionState. The structure SExtractionState contains informationfor extracting a status information from the web page. FIG. 47 shows aflowchart on how the structure is used to extract the statusinformation. The vector structure contains information for extractingall the information except vendor and model from the web page. Thestructure SExtractionState uses information from the structureSKeyValueInfo to obtain the status information from a web page.m_infoType, m_nRelativePriority, m_sFrontDelete1, m_sFrontDelete2, andm_sBackDelete of SExtractionState are the same as those in the structureSKeyValueInfo. The iterator m_CurrentPreconditionItr will be used toiterate through the key strings in the vector of sKey of SKeyValueInfowhile the iterator m_EndItr will be used to point to the end of thevector of sKey. The iterator m_CurrentPreconditionItr will point to thesKey and is initially set to point to the first element of the vector ofsKey. If a line of the web page contains the sKey, then the iteratorwill be incremented so that it will point to the next sKey that will besearched for. It the iterator reaches the end (equals m_EndItr), thethen next line of the web page will contain the desired statusinformation. m_LineState is the enumeration ELineStatus with valuesePreTargetLine, eTargetLine, and eFinished. The value of m_LineStatemaintains the state of finding the status information. If m_LineState isePreTargetLine, then the system is still searching the for the sKey ofthe vector to locate the status information. As long as the iteratorm_CurrentPreconditionItr is not at the end of the vector, m_LineState isePreTargetLine. Once the iterator m_CurrentPreconditionItr reaches theend of the vector, all the sKey of the vector has been found andm_LineState becomes eTargetLine and the status information is extractedfrom the next line of the web page. Once the status information isextracted from the next line of the web page, m_LineState becomeseFinished.

FIG. 43 is a sequence diagram that shows the vendor name, model name,and unique identifier being obtained from the device's web pages. Thefunction obtainXXX( ) of CHTTPProtocol where XXX is Vendor, Model,UniqueID, or VendorModelUniqueID, initiates the sequence to obtaininformation about the device. The function obtain XXX( ) calls its ownfunction obtainDeviceInfo( ) which obtains the vendor name, model name,and unique ID. All the sequences following obtainDeviceInfo( ) in thediagram are performed within the function. The HTTP session is initiatedby a call to the function initiateHTTP( ) of CHTTPaccess. Then thefunction obtainVendorModel( ) of CHTTPaccess is called to obtain themodel name from the device's web page. This function may be calledmultiple times with different input web pages until the model isobtained. If the model name is obtained, the normalized vendor name isknown based upon the map structure m_VendorModelSearchMap of FIG. 39.Once the model name is obtained, the function obtainNormalizedModelID( )of CNormalizedVendorModel is called to obtain the normalized model nameand the vendor model ID. Then the unique ID of the device is obtained bycalling its own function obtainUniqueIDInDevice( ). Within this functionthe map structure m_UniqueIDSearchMap of FIG. 40 is used to obtain theweb page that contains the unique ID and the call to functionobtainDataFromHTTPFile( ) of CHTTPaccess will obtain the unique ID fromthe web page. With the vendor and model known, a call to its ownfunction populateVendorModelStatusMap( ) will populate the map structurem_VendorModelStatusMap of FIG. 41 with information about all the statusinformation that will be obtained from the web pages of the device.populateVendorModelStatusMap( ) will populate the map structure withinformation from the tables of FIG. 19 in the support database withcalls to obtainHTTPWebPageKeyValueInfo( ) of CHTTPODBC. The HTTP sessionis closed by the call to function closeHTTP( ) of CHTTPaccess.

FIG. 44 is a flowchart that describes the process of obtaining the modelname from the web page of a device that will use the map structure ofFIG. 39. The map structure shows that for a given vendor, there aremultiple web pages corresponding to different models where the modelname can be extracted. If the web page is accessible, then the vendorname is known since it is associated with the web page. Since manymodels may use the same web page for indicating the model name, all themodel names are searched for in each line of the web page until themodel name is found. In the flowchart, a line is obtained from the webpage. If no more lines can be obtained, then the process to obtain themodel name failed even though the web page was accessible and the vendorname is known. If a line was obtained, the line is checked to see if anyof the model names are found in the line. If none, then obtain the nextline of the web page. Otherwise, from the model name found in the line,obtain the normalized model name and the process is completed.

FIG. 45 is a sample portion of a web page of a device that contains themodel name of the device. This portion is the HTML source of the webpage which is not visible in a web browser. As can be seen from the webpage, the model name for the device is the LaserJet 9000. The process ofFIG. 44 would read the first line of the web page which contains themodel name. Then each model name that could be found from this web pagewould be searched for in this line. If the LaserJet 9000 is notsupported by the HTTP protocol, then no model name would be found andthis device would not be supported and monitored by the HTTP protocol.Otherwise, the unique ID of the device would be obtained, theinformation to extract status information from the device would beobtained, and status information would be obtained from the device.

FIG. 46 shows sample values for the map structure of FIG. 39 that areused to obtain the model name from the web page shown in FIG. 45. Toobtain the model name, the system will go through the map structure onevendor at a time, attempt to access the web page in the vector pairs,and if the web page is accessible, determine if one of the model namesin the vector of pairs can be found. For the sample values, the vendorHP would be used first. From the vector of pairs, the system willattempt to access the web page“/hp/device/this.LCDispatcher?dispatch=html&cat=0&pos=1”. If the webpage is accessible, then the system would read lines from the web pageto find one of the model names—“HP Color LaserJet 4550”, “HP LaserJet9000 Series”, or “hp color LaserJet 550”. If any are found, then themodel name is obtained. Otherwise, the system will check the next webpage “/hp/device/this.LCDispatcher?nav=hp.Config” corresponding to HPand see if the model name “hp LaserJet 4345 mfp” can be found. If noneof the web page corresponding to HP can be accessed, then the process isrepeated for Xerox.

FIG. 47 is a flowchart that describes the process of obtaining thestatus information from the web page of a device that uses the datastructures of FIGS. 40, 41 and 42. The map structure of FIG. 41 showsthat for a given vendor and model, there are multiple web pages fromwhich different status information can be extracted. Each web page isaccessed to extract the status information. In the flowchart, thecomponents of the SExtractionState of FIG. 42 are used. This flowchartshows the process that would obtain one status information from the webpage. However, more than one status information could be extracted fromthe web page at the same time so the process in the flowchart wouldapply for unique ID and all status information obtained from the webpage. The testing of the left side, steps 4700-4710 of FIG. 47, are donefor each of the vector of SExtract State shown in FIG. 42. The iteratorm_CurrentPreconditionItr of SExtractionState is checked to see if thereare any sKey in the vector of sKey used to locate the line containingthe status information. If there are more sKey, then a line is obtainedfrom the web page. If the line does not contain sKey, the another lineis obtained from the web page. If the line does contain sKey, incrementthe iterator to the next sKey. If there are no more sKey(m_CurrentPreconditionItr equals m_EndItr), then the status informationwill be on the next line. The next line if obtained from the web page.All strings up to and including m_sFrontDelete1 is deleted from thestring containing the line of the web page containing the statusinformation. Then all strings up to and include m_sFrontDelete2 isdeleted from the line. Then all strings including and afterm_sBackDelete is deleted from the line. All the HTML representation ofspaces in the line such as & nbsp; is converted to a blank space. Allthe leading and trailing spaces in the line are removed leading thestatus information. The right side of the flowchart shown in FIG. 47(steps 4720-4732) is performed by CExtractValueFromLine in FIG. 37.

FIG. 48 is a sample portion of a web page of a device that containsstatus information. The status information is the toner level ofdifferent colors. The status information is found within the javascriptof the web page. To obtain the status information for all the colortoner levels, the sKey strings must be identified to locate the linecontaining the information. For example to locate the line containingthe black toner level, the only sKey string needed to locate the line is“var YellowTonerPer”. Another example to locate the line containing thecyan toner level, the sKey strings needed are “functionRemainTonerOption( )”, “else”, and “{”.

FIG. 49 shows sample values for the map structure of FIG. 41 used toobtain status information from the web page shown in FIG. 48. To obtainthe status information using the map structure, the vector of pairs inthe map for the vendor and model name is obtained. The vector of pairswill contain information about all the web pages that will containstatus information for the vendor and model and what status informationcan be extracted from the web pages. The sample values only show one webpage for the Samsung CLP550 printer in which four status information canbe extracted (color toner levels). To extract the status informationfrom the Samsung CLP550, the system will go through the vector of pairs.For each pair, the system will access the web page and then read linesfrom the web page until all the status information that can be extractedare obtained. For the sample values, the system will access the web page“/panel/setup.htm” of the Samsung CLP550 printer. The system will readall the lines of the web page looking for the sKey string associatedwith each status information. If the sKey strings are all found for astatus information, then the status information is extracted from thenext line using the front delete and back delete strings. Once all thestatus information is obtained, the system accesses the web page in thenext pair of the vector to obtain status information from the next webpage. This processes is repeated for all the web pages.

FIG. 50 shows sample values for the vector structure of FIG. 42 used toobtain status information from the web page shown in FIG. 48. For agiven web page, the vector structure contains a structureSExtractionState for each status information. Each structure will beused to locate the line containing the status information and to extractthe desired information from the line. The value of m_LineState at thestart is ePreTargetLine. As each line is read from the web page, thesKey in the vector pointed to by each m_CurrentPreconditionItr arechecked to see if they exist in the line that was read. If so, them_CurrentPreconditionItr is moved to the next key. This is repeateduntil there are no more sKey (when m_CurrentPreconditionItr equalsm_EndItr). If there are no more sKey, then m_LineState changes toeTargetLine indicating that the next line read from the web page willcontain the status information and the front delete and back deletestrings of SExtractionState will be used to extract the information.

FIG. 51 shows a package diagram of the SNMP package that is used toextract information from the MIB of a device. FIG. 51 shows the packagediagram for a first embodiment of the SNMP package 2304. This package isresponsible for determining the vendor and model of network devicessupported by the SNMP protocol and the information to be obtained fromthe network devices by SNMP protocol, and for accessing the networkdevice through the SNMP protocol to obtain information from the networkdevices. The package contains the packages SNMPaccess, SNMPODBC, theclass CSNMPProtocol, and uses the classes CNormalizedVendorModel 2314,CAbsProtocol 2308, and CRecordset 2310 as described in FIG. 22. TheSNMPaccess package implements the SNMP protocol to access the networkdevices and to obtain information from the network devices. The SNMPODBCpackage accesses and obtains information from the database about vendorand model of network devices supported by the SNMP protocol and theinformation to be obtained from the network devices by SNMP protocol.The CSNMPProtocol class is a class derived from the CAbsProtocol class2308. CSNMPProtocol obtains the necessary information from the networkdevices using the SNMP protocol. CSNMPProtocol provides the method forall the interface functions of CAbsProtocol 2308 as described in FIG.22. FIG. 51 also shows the functions of the packages SNMPaccess andSNMPODBC that CSNMPProtocol uses. The SNMPODBC package uses the classCRecordset to obtain information from the database. The SNMP protocolobtains normalized vendor names and normalize model names fromCNormalizedVendorModel so that it can use names which are common to allprotocols.

FIG. 52 shows a map structure that is used in the SNMP package of FIG.51 to extract the model name from the MIB. The map structurem_VendorModelSupport is an attribute member of CSNMPProtocol. The key tothe map is a string for the vendor name. The value to the map is avector of strings for all the models that are supported. The vendor namewill be capitalized and does not correspond to the normalized vendorname. The model names are the names that will be found in the MIB of thedevices and do not correspond to the normalized model names. The SNMPpackage will obtain the string containing the model name of the devicefrom the MIB for a given vendor. Then the SNMP package will check whichof the model names in the vector is found in the string to determine themodel name. This map structure is populated with information from thetables in FIG. 18 of the support database.

FIG. 53 shows a map structure that is used in the SNMP package of FIG.51 to determine the vendor name, model name, and unique ID from the MIBof a device. The map structure m_VendorOIDInfoMap is an attribute memberof CSNMPProtocol. The key to the map is a string for the vendor name.The value to the map is a structure SVendorOIDInfo which consists ofthree strings that represent the object identifier. m_sEnterpriseOID isthe enterprise object identifier that corresponds to a vendor. Theenterprise object identifier uniquely identifies the vendor of a device.m_sOIDForModel is the object identifier that is used to obtain thestring from the MIB of the device that will contain the model name. Thisstring along with the vector of model names in the data structure ofFIG. 52 will determine the model name of the device. m_sOIDForUniqueIDis the object identifier that is used to obtain the string from the MIBof the device that will contain the unique ID of the device. The vendorname will be capitalized and does not correspond to the normalizedvendor name. This map structure is populated with information from thetables in FIG. 18 of the support database.

FIG. 54 shows a map structure that is used in the SNMP package of FIG.51 to extract the status information from the MIB of all devices thatare monitored. The map structure m_VendorModelOIDInfo is an attributemember of CSNMPProtocol. The key to the map is the normalized vendorname. The value to the map is another inner map. The key to the innermap is the normalized model name (except for GENERIC). For a givenvendor, the GENERIC model entry indicates that certain statusinformation can be obtained from the device for all models of the givenvendor. The value to the inner map is a vector of pairs that will beused to obtain the status information from the MIB of the device. Oncethe vendor and model are determined for a device, information aboutobtaining status information from the device is obtained from thesupport database and added to the map structure.

FIG. 55 shows a map structure that is used in the SNMP package of FIG.51 for mapping the normalized vendor and model name with the vendor andmodel name as known by SNMP. The key to the map is a string for thenormalized vendor name and model name separated by %. The value to themap is a pair where the first element of the pair is the vendor name andthe second element of the pair is the model name. The vendor name andmodel name in the pair are names for the device as known by SNMPprotocol.

The map structures of FIGS. 52 and 53 are used during the initializationprocess only when the discovering the vendor name, model name, andunique ID of the device. The map structure of FIG. 55 is used to helppopulate the map structure of 54 to determine the status information tocollect from all the devices discovered during the initializationprocess.

FIG. 56 is a flowchart that describes the process of obtaining thevendor name, model name, and unique ID of the device through the SNMPprotocol. The system initiates the SNMP session with the device. If thesystem fails to initiate the SNMP session, the process is complete andthe SNMP protocol will not be used to obtain information from thedevice. If the system initiates an SNMP session with the device, thesystem obtains the system description from the MIB of the device andconverts the string of the system description to all upper cases. Inmost cases, the system description will contain the vendor name. Each ofthe vendor names in the map structure of FIG. 53 will be checked to seeif the vendor name is in the system description. If the system failed toobtain the system description or the system description did not containany of the vendor names in the map structure, then the system obtainsthe enterprise OID from the device. Some devices such as the KonicaMinolta Magicolor 3300 printer will not have the vendor name in thesystem description. Each of the enterprise OID in the map structure ofFIG. 53 will be checked to see if it can be found in the obtainedenterprise OID. The vendor is obtained when one of the enterprise OID inthe map (FIG. 53) is found. For the Konica Minolta Magicolor 3300printer, the enterprise OID can be used to identify the vendor. If thesystem failed to obtain the enterprise OID or the enterprise OIDobtained did not contain any of the enterprise OID in the map structureof 53, the process is complete. However, SNMP protocol can be used toobtain generic information from the device since the SNMP session can beinitiated. The sequence to obtain the vendor name cannot be reversed.The system description must be checked first before the enterprise OID.In most cases, the system description is sufficient to obtain the vendorname. Only a few cases require the enterprise OID to identify thevendor. The vendor name may not be correctly identified if theenterprise OID is checked first for the vendor name before the systemdescription. The reason is that many vendors used enterprise OID of HPso that they would be identified as HP if the enterprise OID was used toidentify the vendor. However, the system description would successfullyidentify the models of Samsung and Brother correctly. If the vendor nameis obtained through either the system description or the enterprise OID,the system attempts to obtain the model name of the device. The systemuses the object identifier in m_sOIDForModel corresponding to the vendorname obtained from the map structure of FIG. 53 to obtain the stringfrom the MIB of the device that contains the model name. The each modelname in the vector corresponding to the vendor name obtained from themap structure of FIG. 52 is checked to see if it is found in the stringobtained from the device. Whether or not the model name is obtained, thesystem will next attempt to obtain the unique ID of the device. Thesystem uses the object identifier in m_sOIDForUniqueID corresponding tothe vendor name obtained from the map structure of FIG. 53 to obtain thestring from the MIB of the device that contains the unique ID. Whetheror not the system obtains the string, the system updates SNMP supportfor the device. Updating SNMP support populates the map structure ofFIG. 54 with the information to obtain status information for a vendorand model of the device. If only the vendor is known, then genericstatus information is added to the map structure. If the vendor andmodel are known, then the generic status and model specific statusinformation is added to the map structure. The vendor and model nameobtained through SNMP are names which are in the SNMP tables of FIG. 18in the support database. These names are used to match the names whichare obtained from a device to determine the vendor and model name. Thesenames may correspond to names used to identify the vendor and modelnames in other protocols. However, to guarantee that the vendor andmodel name obtained by the SNMP protocol is known by all otherprotocols, normalized vendor and model names are used. The normalizedvendor and model names are common names that are shared among protocols.Therefore, the normalized vendor name for the vendor name obtained bythe SNMP protocol is obtained using the lookup table described in FIG.30 and the normalized model name for the model named obtained by theSNMP protocol is obtained using the lookup table described in FIG. 31.

Although the present invention is shown to include a few devices, whichrequire monitoring, connected to a network, it will be appreciated thatany number of devices may be connected to the network without deviatingfrom the spirit and scope of the invention. Also, the present inventionmay also be applied in a home environment wherein various devices needto be monitored and controlled.

Embodiments of the present invention enables the monitoring of thevarious devices in a multi-vendor environment and further facilitatesretrieving and displaying detailed information in a user-comprehensibleor user-friendly manner even without having specific private managementinformation base (MIB) information. Furthermore, the information can beredistributed from a monitoring station (902) to other computer (940)using various methods such as SMTP, FTP, or Web Services.

The controller of the present invention may be conveniently implementedusing a conventional general purpose digital computer or amicroprocessor programmed according to the teachings of the presentspecification, as will be apparent to those skilled in the computer art.Appropriate software coding can readily be prepared by skilledprogrammers based on the teachings of the present disclosure, as will beapparent to those skilled in the software art. The invention may also beimplemented by the preparation of application specific integratedcircuits or by interconnecting an appropriate network of conventionalcomponent circuits, as will be readily apparent to those skilled in theart.

The present invention includes a computer program product residing on astorage medium including instructions that can be used to program acomputer to perform a process of the invention. The storage medium caninclude, but is not limited to, any type of disk including floppy disks,optical discs, CD-ROMs, and magneto-optical disks, ROMS, RAMs, EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions.

Numerous modifications and variations of the present invention arepossible in light of the above teachings. It is therefore to beunderstood that within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described herein.

1. A method for determining a normalized vendor name and a normalizedmodel name of a monitored device in which information obtained from themonitored device varies in accordance with a communication protocolused, the method comprising: accessing, by a monitoring device, themonitored device using a first communication protocol, of a plurality ofdifferent communication protocols, to obtain information from themonitored device; determining, by the monitoring device, a vendor nameand a model name of the monitored device from the information obtainedfrom the monitored device to form a determined vendor name and adetermined model name; accessing, by the monitoring device, a vendordatabase that maps a plurality of vendor names to a single normalizedvendor name, wherein a key of the vendor database is one of theplurality of vendor names and the respective value of the key is thesingle normalized vendor name, wherein the plurality of vendor names areobtained from the plurality of different communication protocols and thesingle normalized vendor name is used by the plurality of differentcommunication protocols to refer to the monitored device; determining,by the monitoring device using the determined vendor name, a normalizedvendor name of the monitored device based on a mapping between thedetermined vendor name and normalized vendor names in the vendordatabase, wherein the determined vendor name is used as a key formapping; accessing, by the monitoring device, a model database that mapsa plurality of normalized vendor names and a plurality of model names toa single normalized model name, wherein a key of the model database isthe pair of a single normalized vendor name and the one of the pluralityof model names and the respective value of the key is the singlenormalized model name, wherein the plurality of model names are obtainedfrom the plurality of different communication protocols, and the singlenormalized model name is used by the plurality of differentcommunication protocols to refer to the monitored device; determining,by the monitoring device using the determined normalized vendor name andthe determined model name, a normalized model name of the monitoreddevice based on a mapping between the determined normalized vendor nameand the determined model name with normalized model names in the modeldatabase, wherein the pair of the determined normalized vendor name andthe determined model name is used as a key for mapping; and updating themonitoring device with the obtained information, wherein all theplurality of different communication protocols use the determinednormalized model name of the monitored device as an identifier of themonitored device.
 2. The method of claim 1, further comprising:accessing, by the monitoring device, the monitored device using a secondcommunication of the plurality of different communication protocols toobtain a vendor name of the monitored device, wherein the vendor namesobtained by the first and second communication protocols differ; andaccessing, by the monitoring device, the vendor database.
 3. The methodof claim 1, further comprising: accessing, by the monitoring device, themonitored device using a second communication protocol of the pluralityof different communication protocols to obtain a model name of themonitored device, wherein the model names obtained by the first andsecond communication protocols differ in one of capitalization, spacing,punctuation, and hyphenation; and accessing, by the monitoring device,the model a database.
 4. The method of claim 1, wherein the step ofdetermining a normalized model name comprises: creating a stringincluding the determined normalized vendor name and the determined modelname; and determining whether the creating string exists in the modeldatabase.
 5. A computer program product having a computer readablemedium for determining a normalized vendor name and a normalized modelname of a monitored device in which information obtained from themonitored device varies in accordance with a communication protocolused, comprising: instructions for accessing, by the monitoring device,the monitored device using a first communication protocol of a pluralityof different communication protocols to obtain information from themonitored device; instructions for determining, by the monitoringdevice, a vendor name and a model name of the monitored device from theinformation obtained from the monitored device to form a determinedvendor name and a determined model name; instructions for accessing, bythe monitoring device, a vendor database that maps a plurality of vendornames to a single normalized vendor name, wherein a key of the vendordatabase is one of the plurality of vendor names and the respectivevalue of the key is the single normalized vendor name, wherein theplurality of vendor names are obtained from the plurality of differentcommunication protocols and the single normalized vendor name is used bythe plurality of different communication protocols to refer to themonitored device; instructions for determining, using the determinedvendor name, a normalized vendor name of the monitored device based on amapping between the determined vendor name and normalized vendor namesin the vendor database, wherein the determined vendor name is used as akey for mapping; instructions for accessing, by the monitoring device, amodel database that maps a plurality of normalized vendor names and aplurality of model names to a single normalized model name, wherein akey of the model database is the pair of a single normalized vendor nameand the one of the plurality of model names and the respective value ofthe key is the single normalized model name, wherein the plurality ofmodel names are obtained from the plurality of different communicationprotocols, and the single normalized model name is used by the pluralityof different communication protocols to refer to the monitored device;instructions for determining, by the monitoring device using thedetermined normalized vendor name and the determined model name, anormalized model name of the monitored device based on a mapping betweenthe determined normalized vendor name and the determined model name withnormalized model names in the model database, wherein the pair of thedetermined normalized vendor name and the determined model name is usedas a key for mapping; and instructions for updating the monitoringdevice with the obtained information, wherein all the plurality ofdifferent communication protocols use the determined normalized modelname of the monitored device as an identifier of the monitored device.6. The computer program product of claim 5, further comprising:instructions for accessing, by the monitoring device, the monitoreddevice using a second communication of the plurality of differentcommunication protocols to obtain a vendor name of the monitored device,wherein the vendor names obtained by the first and second communicationprotocols differ; and instructions for accessing, by the monitoringdevice, the vendor.
 7. The computer program product of claim 5, furthercomprising: instructions for accessing, by the monitoring device, themonitored device using a second communication protocol of the pluralityof different communication protocols to obtain a model name of themonitored device, wherein the model names obtained by the first andsecond communication protocols differ in one of capitalization, spacing,punctuation, and hyphenation; and instructions for accessing, by themonitoring device, the model database.
 8. The computer program productof claim 5, wherein the instructions for determining a normalized modelname comprises: instructions for creating a string including thedetermined normalized vendor name and the determined model name; andinstructions for determining whether the creating string exists in themodel database.
 9. A system for determining a normalized vendor name anda normalized model name of a monitored device in which informationobtained from the monitored device varies in accordance with acommunication protocol used, the system comprising: a processor; anapplication program, executed by the processor, wherein the executingapplication program comprises: means for accessing, by a monitoringdevice, the monitored device using a first communication protocol, of aplurality of different communication protocols, to obtain informationfrom the monitored device; means for determining, by the monitoringdevice, a vendor name and a model name of the monitored device from theinformation obtained from the monitored device to form a determinedvendor name and a determined model name; means for accessing, by themonitoring device, a vendor database that maps a plurality of vendornames to a single normalized vendor name, wherein a key of the vendordatabase is one of the plurality of vendor names and the respectivevalue of the key is the single normalized vendor name, wherein theplurality of vendor names are obtained from the plurality of differentcommunication protocols and the single normalized vendor name is used bythe plurality of different communication protocols to refer to themonitored device; means for determining, by the monitoring device usingthe determined vendor name, a normalized vendor name of the monitoreddevice based on a mapping between the determined vendor name andnormalized vendor names in the vendor database, wherein the determinedvendor name is used as a key for mapping; means for accessing, by themonitoring device, a model database that maps a plurality of normalizedvendor names and a plurality of model names to a single normalized modelname, wherein a key of the model database is the pair of a singlenormalized vendor name and the one of the plurality of model names andthe respective value of the key is the single normalized model name,wherein the plurality of model names are obtained from the plurality ofdifferent communication protocols, and the single normalized model nameis used by the plurality of different communication protocols to referto the monitored device; means for determining, by the monitoring deviceusing the determined normalized vendor name and the determined modelname, a normalized model name of the monitored device based on a mappingbetween the determined normalized vendor name and the determined modelname with normalized model names in the model database, wherein the pairof the determined normalized vendor name and the determined model nameis used as a key for mapping; and means for updating the monitoringdevice with the obtained information, wherein all the plurality ofdifferent communication protocols use the determined normalized modelname of the monitored device as an identifier of the monitored device.10. The system of claim 9, where the executing application programfurther comprises: means for accessing, by the monitoring device, themonitored device using a second communication of the plurality ofdifferent communication protocols to obtain a vendor name of themonitored device, wherein the vendor names obtained by the first andsecond communication protocols differ; and means for accessing, by themonitoring device, the vendor database.
 11. The system of claim 9, wherethe executing application program further comprises: means foraccessing, by the monitoring device, the monitored device using a secondcommunication protocol of the plurality of different communicationprotocols to obtain a model name of the monitored device, wherein themodel names obtained by the first and second communication protocolsdiffer in one of capitalization, spacing, punctuation, and hyphenation;and means for accessing, by the monitoring device, the model database.12. The system of claim 9, wherein the means for determining anormalized model name comprises: means for creating a string includingthe determined normalized vendor name and the determined model name; andmeans for determining whether the creating string exists in the modeldatabase.